TG码农应该不少，实在忍不住要吐嘈Java的开发……

听楼主描述是你不懂而已。自己三脚猫功夫不肯学新东西就怪语言。

正常现象。

spring ioc 又不是今天才出的技术，居然还有人认为lz不懂，做java的井底蛙确实不少

你仔细看我的帖子，没提到阿里的核心模块直接用spring，都说的是java。

这帖子里面可以好几个java码农质疑lz不懂spring ioc来着的，你们nb，你们什么都懂

话说java宣传自己面向对象，是不是这样比较符合直觉，所以吸引的弱鸡也多

别的语言就不能面向对象吗

看着看着不禁看了下发帖时间，有种时间穿越的感觉。
现在Java都快到原来PHP在鄙视链的位置了。哪里还有这种优越感

spring整套框架对于企业领域更适合，倒不一定适合lz的场景，还有就是感觉lz公司的java都是阿里京东出来的核心架构师，口气那么狂...

不知道为什么国内一说Java就是Spring，难道大家不知道还有Java EE的么？虽然Java EE不是框架

问题出来了 那些认真学习的因为资历低 要学习要长进 自然学习热情高
java的 资历高 人生经历丰富 自然不鸟你

23333

1.2年代的码农表示有了框架后程序员里的水货实在太多了，满口的大道理，是个人就谈架构设计，其实自己都不知道自己在说什么

用几天写一个高并发的服务架构，只加工厂类实现就可以持续扩展了，这种想法的比被楼主吐槽的sb更加sb。

同意楼主观点。 我觉得主要问题就是java 和 spring 非常难学，或者说文档非常差， spring boot 一直在更新， 文档乱七八糟， 版本跟不上。

例如JavaScript，一般学个5年， 90%以上问题，没有难不住的。 而java 5年 我随便说一个其他语言后段框架的类似问题， java都无法解决，或者非常难解决。例如路由不灵活，错误处理不灵活，太多问题了，在2018年 spring 号称这么牛的框架连日志显示还是乱七八糟，其他语言的日志都是图形界面，非常漂亮， java还是一堆堆栈， 这种问题数不胜数，非常不好用。

不好用的原因就是spring 很难学，或者说改进spring的人已经太少了。

java的netty框架在高并发方面已经做的很好了，在这基础上做个数据处理模块真心不是什么大不了的事情，你不信也没办法！乔布斯十年前就说过，开发这行，顶尖的高手开发者和平庸的开发者可以差个上百倍的效率，有时候你花几个月才写出来的程序，换高手几天照样可以吊打你，真的就是这样…

现在软件行当就是因为没有一个权威的认证去客观筛选人才，才使得楼主这种似懂非懂还自以为是的货色泛滥而无法过滤，这就完全依靠招聘的人的水平，一道招聘的人水货，就会招进楼主这样的人，实在是可悲。

明显是这帮人不行啊，人不行写什么出来都是一炮无

如果framework本身提供类似功能尽量不要自己写，涉及长期维护问题。

spring 并不算难学。spring boot 已经很傻瓜化了。我觉得问题反而是太傻瓜化了

所以楼主的马甲是不是机器猫呢？

砍掉重新招，楼主遇到的情况和我一样，只能说现在被互联网这个大环境弄得很多小朋友只会框架开发。离了 框架就什么都不会了。

给多少钱就招多少水平的人。
基础扎实，框架熟练，招进来怕是lz位置不保。

你这扯了半天，最后吐槽Python干啥？

Python哪个例外处理不了了？具体说说看嘛。

听上去你技术确实不怎么行……

就是，看到就好笑，2333

合适的就是最好的， framework难道不是人开发维护的 不用学习成本？ 文档不用人编写积累么，
其实推理出去 能安装软件直接用的就不要开发了， 还能省掉开发人员 请两个运维小工就好，
一些公司老板连域名都1年1续费的， 搞什么高大上框架 长期维护个毛，一不高兴整个团队都砍的，换一班来又说这个框架落后 xxx问题解决不了 只有yyy才是代表最先进生产力

python确实值得喷， 原本想用来写个epoll偷懒一下的，最后各种不顺心 还是回去用c写了个， 也可以说是我python水平不好，

其实就是lz也不行，团队也不行。

感觉lz也有些极端，对自己不熟悉的东西有些排斥，java的很多框架本身是很好的，有其擅长的领域和模式，但是不管滥用还是完全拒绝其本质都是一样的

springboot不就是约定大于配置?人家也没说错啊,你这个确实没通用性.你这个场景下是够用了,但复杂点的场景怎么用?
我以前就碰过一个老项目,运行时间一久就数据库连接过多,我一看代码自己实现的事务,问题实现的不够好session有一种状态下不会close,所以既然用了框架那就没必要自己搞个原生的不说啥了,可能你的业务场景足够用了吧........

我觉得吧LZ也过于自满自己二十年经验了,固步自封要不得的,人真没自己想象的那么功力深厚知识渊博
你自己也没打算深入了解嘛,不然就能直接反驳你看不起的java码农了而不是上论坛吐槽

[本帖最后由 2047 于 2018-12-13 09:46 编辑]

其实这没错，你最后说的就是业内常见的情况，为啥会这样？因为框架会被淘汰啊。

但是当初构建的时候把系统底层就绑在这个框架上了，随着以后产品越做越大，客户越来越多，你的架构就越来越不能动，但是某一天这个架构真的就被官方淘汰了……

不是我耸人听闻，我经常参加公司的产品选型，这种情况很常见，有些就是上市公司，行业内排前三的软件公司开发出来的产品，架构也确实就是淘汰的，二次开发需要用他们公司自己规定的JDK，为了快速开发还要搭配他们自己开发的几个插件，然后干脆就直接给你个他们配置好的Eclipse……

本身功能可能没啥特别，就是业内流行了几十年的玩意，这类东西无论什么语言PHP、Java还是C#其实都有成熟稳定的产品，所以就Java来说本身并没有出彩的地方，但是架构太烂了，因为框架淘汰了，所以要做二次开发真是难上加难，最后只能踢出局。

所以问题回到开始，怎么做架构呢？底层的玩意还真的只能自己写，框架类的，不然一个框架平均几年的生命周期根本没办法支撑你应用的长期持续可发展，人家只要凉了，你整个产品怎么办？本来开发这一行就是日新月异的，一种开发思路其实不会流行太久，所以你说的yyy才是最先进生产力没错，但是老系统怎么办？不换的话吧，很快就可能被新公司的新产品打掉，换的话重构的代价真的搞不好公司就把公司搞死了。


换句话来说，既然不要长期维护，那用PHP、Python之类的其实更好更快，架构稳定下来也好用java之类优化重构。

我也搞产品的，之前团队用php，做东西什么的都很迅速，经常头天说的第二天第三天就搞完了
现在的项目用java，改个需求的时间都是用星期计算的，喷了

核心的业务架构，我一直认为要自己来……其实架构设计行业一直推崇KISS原则是有原因的！
简单意味着变化起来容易，愚蠢意味着容易发现问题，简单问题简单处理，架构尽可能的简单和愚蠢，这往往就是最好的架构设计！
就像我说的这个场景，需求就是数据接收之后处理一下在转发的问题，连数据库都用不到，无非就是并发量特别大，数据格式有点多……
这么简单的需求，非要套个Spring壳子那是有病吗？

你要效率，当然不能找python，这个主要用来快速验证吧。

我感觉你们前面都已经说明白了

首先，这是人的问题，毫无疑问
其次，为什么是java，因为java的框架太强了，以至于很多人没有理解基础就开始用框架，用了框架就觉得自己懂了。实际上很多人都是知其然不知其所以然。就像崆峒派的七伤拳一样，看起来威力很大，其实是折腾了自己而不自知。
还有，很多人没有架构师的能力，却试图做架构师的设计。最后做出来的东西当然是牵一发而动全身的。

这种事我觉得也很常见的，比如有些人没有IDE就不会写程序了，有些人完全不碰命令行编译系统等等。

主要是java，.net这些一上来就一大堆可用的框架 ， 拼拼凑凑就有一个可用的东西 ，
面试这些人的时候 ， 稍微问深入一点，原理。。不知道 ， 出错了咋办。。。不知道 ， 那样改改如何....做不到
还是喜欢写C的人 ， 一个问题可以扣到编译如何如何，内存在哪个角落越界，是比较难学难精， 不过也很锻炼人

事实套了spring只会让业务代码更简单更容易扩展。

人的问题就不要扩展了，你自己不写也应该多学习，你所谓的原生jdbc实现简单，3天一个netty框架，这种玩玩可以，真到线上很难用。提高自己这也是为了避免招到水货。

我是觉得spring的最大作用是大幅减少需要写的代码量。如果用了spring之后代码反而增加了，说明对spring理解有偏差。

还有，不能用google是很多程序员无法成长的原因之一。我身边太多这样的例子。分分钟能google到的stackoverflow上的解释，他们要在百度搜到的国内各种blog上查询加实验几个小时才能搞定。

高并发的潜台词是高可用，在这种情况下，服务停一秒钟都是不可接受的，我公司的详单系统就是这样，每月500亿条数据，考虑晚上没啥数据白天平均一秒3.8万条，就是采用Java分布式解决，不知楼主的数据量是多少。
然后因为后台是上百个节点的集群，每个节点出问题宕个几分钟是常事，这是就要求把它当前处理的业务秒级切换到其它节点，未提交的事务立刻回滚，否则出了问题神仙也难找回数据。这些事情框架已经搞定的差不多了，我们在其上遵循规则二次开发就不会出大问题。如果抛开业务场景，使用servlet也能做相同的事，只是不保证高可用，出问题就停业务，然后整个团队被开。

是的，ls说的场景就是java框架比其他强的地方

你们java组的技术栈有问题，tech lead估计不太灵，传统的spring web更适合做业务系统增删改查什么的，纯高并发的话应该走netty+rpc的路子，或者reactor

不是码农，非抬杠。只是从你的描述中，高并发和高可用这俩概念是互斥的。

重新爬了一遍楼，相信楼主本身技术应该是不差的，问题在于初期架构没有盯紧，如果一开始就强推netty框架，哪怕自己撸代码把架子定好，后面的人估计也懒得重构了，现在明显这块已经成了生产力瓶颈，只能从考核角度约束了，每次迭代都拖后腿的话，java组也不好意思不重构吧？

事实上，中大型公司里的架构推进几乎都是从上至下强制的，没什么好商量的，不然要你架构师干啥

可以用高富帅这三个字的关系来理解高并发和高可用，缺一样系统的价值就会降低，程序员的劳动价值就会变得不值钱。

明明不是高帅富的关系好不好23333。你设想一下在你说的那个场景里如果没有为了可用性做出的各种举措，肯定并发性大大提高了

只考虑并发不考虑可用称之为玩具网站，想想看玩具能干什么。

关键楼主只是说高并发，没说要高可用。指出一下你逻辑上的问题而已。

高并发的场景很多的，并不只有网站的！其实就这点来说其实我觉得很明显大家根本不在一个层面上……
这也是个很常见的问题，就好像你说小学生说为什么1+1=2，他会和你说这个问题太简单了，但是你和数学博士说你知道为什么1+1=2的时候，他会告诉你他不懂！
然后你给小学说你会解多元多次方程式吗，小学生觉得这太难，但是你和数学博士说多元多次的方程式怎么解？人家就成小儿科……
说白了，很多研发的知识体系和所处的能力水平其实很有问题，但他却自我感觉很好，而且还不思进取！
就好像我一提高并发，这楼里好几个哥们就出来嘲笑怎么可能几天就能写个高并发程序，我肯定是个不知天高地厚的菜鸟……
但是实际上就拿netty这个架构来说，随便撸个netty的程序，走socket不连数据库的话（譬如IOT设备或者游戏的在线统计这种）
一台机子背10W、8W的qps轻轻松松啊，甚至网上有100k的案例，因为netty对网络处理模式根本完全不一样啊，真的很难吗？
归根结底，眼界决定了高度
我吐槽最大的问题是，别的语言的开发人员，眼界低，人家认，然后努力的向上爬！
而很多Java的开发，眼界其实也低，但是TMD以为自己用了Java、Spring就很高了，爬都不愿爬……真是日狗了……