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

因为框架可以应付大部分你未来会遇到的坑，而你自己撸的代码只能解决你当前的场景。

需求是高速迭代的，楼主你自己可以试试三个月不用框架写代码。

就我个人看，似乎楼主的这个项目应该不小吧，至少也是大型国企私企的项目吧，我不是替java洗地，不思进取是人的问题，但为啥当初由java团队负责大数据和高并发而不是其他组也肯定是有一定原因的吧，系统设计之初如果耦合度过高，扩展考虑不足，项目又特别庞大，到现在代码一大堆放在那，在不断新增功能的前提下，重构工作量大，出错概率大，抵触也是不可避免的，不如和java组的大牛推心置腹的谈谈，找找问题在哪里，尝试解决这个困境

java程序员这样子基本无解，这是这个语言的特性决定的，它的物理和语言绑定太紧了，需要前期宏观设计，绝不适合迭代开发，而采用框架之后问题更加严重，因为框架就是一整套思想束缚，当你已经适应了框架，就绝不会想出来了。
其实最好的是python，因为这门语言足够灵活，但是又强烈拒绝高性能，这样每一个选python的都必须自己斟酌，谨慎的只是用python实现胶水的作用，其他的工作交给更适合的工具来做。
这样才能保有谦恭的心态以及时刻学习的心态。

吐个槽，如果你后面想说的那个是哥德巴赫猜想的话，那个1+1其实不是1+1=2的意思……

netty做10万八万确实不难，如果是做类似消息推送之类的管理那么多长连接本来就要用netty,就算用上spring，内部业务还是需要用netty，如果不是关键业务不需要考虑7x24运行不需要灰度发布之类的，那确实一台机器就够了，但是如果以后需要扩展到百万级需要多台实例同时运作、需要高可靠的服务质量等等难道还需要自己去弄一套服务治理架构?spring本身就是一个架子而已，怎么用关键是看业务场景，而且既然LZ是带队的，手下提的技术方案不需要评审么？觉得手下的方向不对，又不愿去纠正这种作法很奇怪啊。

这些框架适合做大场面，做小东西是自己给自己加束缚。

强烈拒绝高性能……适度吹捧可以，过份了可不大好，哈哈

多学习，你其实没有真正懂netty和nio，不要看个博客demo就觉得自己懂了。线上你很难做到demo那种理想环境，就不提你前面字符串解释的笑话了。按你的理论，netty都不需要了，原生nio包实现个能跑demo的eventloopgroup和cnannel也就一天，还不需要踩netty那堆坑

就在纠正啊，所以我是说这帮哥们特别烦，别的开发组，你纠正他，和他说道理，他虚心听，认真学，对不对另说，回去想办法转化吸收，不清楚就回来和你讨论
Java这组，你说啥他都觉自己得最才是对的，Spring怎么可能不适用，IOC这么科学的代码怎么会复杂，数据不封装成Bean怎么可能是面向对象，反正为了几行代码，就是你得各种劝说，连哄带骗才行，TMD累的要死……
就好像LS好几个嘲笑什么高并发程序不可能几天写出来的哥们，大家的知识体系眼界都不在一个层面的，很多问题真是鸡和鸭讲，完全说不到一起去啊，真TMD累啊！

我得替python说句话，python是脚本，解释执行的，但是他性能如何取决于你怎么用或者用来干嘛。
因为python的底层其实是c/c++运行库，而且编译安装的时候会针对处理器做并行指令的优化，所以做大规模的代数运算（比如神经网络的向量矩阵运算）的运行效率不见得低。甚至没有经过编译器优化的c++程序做同样的向量运算不一定比python快。
可以理解为用py脚本告诉c运行库执行什么动作。

反之如果是在脚本层面写大量的业务代码或者说大量的原子运算是放在脚本来做的，那么效率自然会低。

只会一点点C++的路过，java那一堆一堆的看着就头大

故事有点意思，让我想起了一些人和一些事

赞同前几页有人説的舍本逐末论，但我同时也更赞同前几页有人提到的 ———— 故事中的剧情冲突点并不是java和spring之间的矛盾

反对诸如一茬不如一茬论、不懂底层就是垃圾论、etc，这类论调其实很滑稽，展开讲，一个当代办公室场景中让一个办公室人员work起来的要素其实可能有几千个，但一个办公室人员不懂得其“底层”的要素可能占了99%或者100%：办公楼不是你建的，内装不是你排的换言之水电网气没一样是你拉的，门禁系统肯定不是你做的，楼前草坪不是你维护的，办公桌不是你造的，你也不需要自己用材料从头拼一个工学椅，桌上的东西从抽纸到水杯到各色文具到抽屉里的雨伞每一样东西都以不同频率支撑这个办公室人员的工作但是没有一样东西坏了或者没了以后是这个人可以用“我自己修一下“的方式解决的

一个岗位到底应该做什么基本上是个人事问题或者説是财务问题或者説是经营问题，跟技术层面的关联性存在但却有限，我个人主张岗位职责的确定最后要落实到服务导向上，你要卖什么、对外你以什么为收入、对内你以什么为争取预算的主张、为此你要做什么怎么做、最后为此你要雇谁要雇几个

一个码农，如果他的显示器黑屏了他肯定不会自己拆硬盘换内存焊电容，因为他“不是修电脑的” ———— 我可以为此喷一个码农“不懂底层”吗，比如“你编程的工具坏了你都不会修，你不懂底层”，这样看上去是不是很弱智？楼主的故事所引发的所谓java和spring、所谓原生代码和框架、楼主的主张、楼主手下java组员的主张、楼里一些回复的各种主张，其实主要是在争论对一个java码工来说，到底哪些部分是外部性的（工具、素材、资源），到底哪些东西是内部性的（其岗位本身的职责、人员应当具有的竞争力），这个问题可以因经营场景的不同有千种结果

思考几个问题，PHP组员效率高、学习能力强、学到新技术就愿意重构自己的老代码，那么为什么不培养这些人做java？或者为什么不雇佣更多”类似他们那样的人“来代替现在的java组员？java组员效率上不符合上司期望、技术认知与上司南辕北辙、那么他们存在于所在之处的竞争力或者説议价能力到底是什么？

归根到底，人的行为并不会因为”恰好“进入了某个特定的技术栈而改变，”做某个工作的人很差但是只有他们能做“从一开始就是不存在的

当然了，从经验出发，我预言故事中的PHP组员会成长为事多钱少勤奋有为、上司招他们即来呼他们即去的存在，与此同时故事中的java组员会成长为事少钱多推诿摆烂、而且上司叫他们叫不动的存在

用最朴素的话语概括整个故事梗概，其实就是一个java组员的武德高于楼主，楼主的武德高于php组员的故事……

www

只能说撸主公司那边做java的太辣鸡了

程序员都一样的, 只能说你的java程序员的水平有问题,或者说带头的人有问题, 招的人培养的团队方向有问题, 没人去把握技术方向.

php这类语言属于快速开发向, 快速开发的背景下,框架也是偏向快速解决需求, 初衷就是为了搭个网站论坛分分钟, 自然解决常见需求飞快.

两种语言的面向环境根本不同, java常用的是ee那种面向企业架构而不是java原生本身, 本身就是重架构向的, 没有相关的架构或者技术把控,就是会出现你说的问题.

但是实际上java是有不少快速开发的开源框架的, spring现在也有类似boot这种快速开发方向, 只不过没有一定的大牛带着, 普通程序员一般只能用最常见的老重框架去做'网站', 结果就是你说的现状了.

生产还是高并发处理他们处理的方式没有错啊

你自己也说了,java这上面本身就有很多可学的, 哪怕是开源的框架方面, 不学是个人的事. 好的程序员可以轻松精通多种语言,我接触过的好的开发不少都是java出身,之后c#,flex,android,python有需要研究研究就能起项目, 明明是做后端的研究javascript就可以自己写刷票程序.还是在于人,在于研发团队带头的榜样.

另外还有一个问题就在于培训学校现在越来越快餐, java培训是重点大户,一个是用人单位多,二是转型另一个火热职业方便:android. 结果就出现太多培训学校出来的,靠着背一些面试题,或者做(抄)过一些demo就进行业了,
大数量下自然素质很难保证.php反而现在是小众,招人不易,这种情况下真爱或者有过相当的经验的人才会坚持. 所以招人时候的筛选非常重要, 能不能发现潜力很重要

[本帖最后由 LHO 于 2018-12-13 16:59 编辑]

LS几位说的没错，其实PHP和Java并没有高下之分，人才是决定因素。

但是你们忽略的是，现在Java培训遍地都是，生源巨大，反过来良莠不齐的情况也非常多，直接就导致了，Java混子的出现概率比PHP混子、Python混子要高不少，这也是目前的实情。

为什么不培养别人用Java？其实应该明白，有兴趣学几门语言的，怎么会没想过学java呢，现在java的培训体系可以说是所有语言里面最完善完备的，甚至新手教程的前两章内就有对堆、栈是放在内存哪这种经典考题的教学了（所以有人前面说的入职考这个的，这招已经过时啦）。

就我个人的了解，现在为啥会主动学语言的，不会把java语言的权重放在前面，就是因为学Java的太多了

嗯,主要是市场问题,同样都是编程语言,学完难度都差不多,结果同级别php的工资就是比java低(现在好点有限),自然导致了更多人去学java,更不用说前两年火热的安卓.随便一家没名的公司只要招安卓开发,工作经验在3年以下的,放出去,一天至少80封简历就过来了,可想而知'人才'臃肿的程度,有相当多的人甚至连自己简历里吹牛逼的技术问到背都背不出来.
又有太多尤其是垃圾企业应用凭借着商务关系和返点套路活在社会各个领域,这些垃圾软件通常多年没有更新,但是又必须使用,大量的外包和外派人力要去维护那些jdk6.0为基础的垃圾项目,每年出产的大量'人才'就是为这个市场服务的.

我说实话, 这年头你有本事搞到服务器挂掉老板笑疯, 说明公司业务增长非常快

现在性能根本不是问题, 都是集群架构, 加几台机器又不是什么大事

啥语言根本不重要

真到了一天上亿访问量时候, 公司规模肯定可以了, 自然能有大牛来, 那时候才是考虑什么架构的时候

归根结底就是非要拿开发大型项目的框架来开发中小型项目，杀鸡用牛刀，效率低还自我感觉良好。
真想问问这些人用不用青龙偃月刀削苹果。

讲道理，不想招只会CRUD的，面试时聊聊天过滤掉很容易，这种人基础不好。

架构这东西就是要迭代的, 要有个人说我必须开始就用xxx, 要不然以后没法用, 只能说明这人根本没经历过真正的设计, 迭代, 是个菜鸟而已, 顶多看了几本书

那个大公司不是慢慢根据业务发展, 调整技术架构的

喷了，写java都这么牛逼了，我们写c艹的不是要上天

貌似很有道理的样子

本帖最后由 11508721 于 2018-12-13 20:03 通过手机版编辑

就你们这些上班时间还在上TGFC的，我看水平都不咋地！

看我抓倒了什么，zhouli大大，是正品还是冒牌的？ 现在八卦都没了么？

你这怎么还停留在一台机器解决10w 8w的问题呢，都8102年了，技术发展早就到了以云服务，以SAAS为主的阶段。
我觉得JAVA组LEADER说不定就看不起你，思维落后，脱离时代，还自己写个简单框架就开搞的作坊工作方式。
再说了，都带队了，要以软件工程的思维来治理团队，JAVA那么多条条框框，恰恰解放了程序员的手脚，让团队专注于业务。你现在还让团队去纠结网络字节传输自己控制，结果就导致你整个项目不可控。你团队有个大牛，撸个框架，算是跑起来了，大牛辞职了，换个人呢？谁弄的懂？出问题？谁解决？ 而要是以标准的SPRINGBOOT来搞，市场上会的人一堆堆，随便就找个人可替代，换你是资本方，你怎么考虑？

你们JAVA团队要是现在发版本还是要停服务器的，讲真，你们的JAVA架构体系太落后了，而目前我看起来最大责任就是你了。

你前面说的还比较认同，但你截图的文章就很奇怪了…python从来不会magicaly work，也不会magicaly not work，虚拟机源码就在那儿，看一眼就能搞清楚了，哪来的magic…

飘过

这么说吧，数据库随便改个字段确实很危险，大企业没人知道会出什么问题。

游戏码农路过，C++出身，现在基本用u3d
我很了解楼主的感想，因为java是前10年里培训班的主力军，虽然是人的问题，但平均水平是真的不行，不过可能是行业细分不同，我们自己一般就兼职维护安卓的简单的java代码，都是安卓activity,intent原生那套，加上一些jni，那种纯做curd的java我们很少接触，毕竟游戏行业面试很偏操作系统和渲染，他们和我们不是一个层面的

C艹必须上天，哈哈

tg码农这么多，没前途啊

本来还挺同意楼主观点的，看这段感觉楼主彻底露怯了， 哥德巴赫猜想的1+1问题只是一个代称，不是指学龄前数学里面的1+1=2，汗~~~

好了好了，我知道青龙偃月刀苦练30年就能削苹果了……

我是这没想到泥潭竟然这么多码农……

java给我感觉是现在越来越容易上手了，springboot比之前省事得多，做restful接口很方便。java很吃框架，我发现部分java开发人员非常喜欢全家桶，比如操作数据一定要用jpa，其实我更喜欢mybatis，比较灵活。

现在都热兵器时代了，你还用刀。。~~~

你指望就是要削个苹果那的确不应该用JAVA。

搞技术的还是要与时俱进呢么，再说搞了十来年的程序，现在什么语言对我来说就是工具而已，作为主管，你自己都不做好技术选型，这就不应该了。

你的意思是因为现在是热兵器时代了，所以削苹果就应该用热兵器？？？

Java当然可以削苹果，本来语言只是一个工具……
问题是公司只要削苹果，结果Java抬来一台CNC车床，然后说这个不仅能削苹果，还能造宇宙飞船，不过操作比较复杂，我要先学个一年半载……

是这个道理，选第三方package还要看看用户数量，维护团队活跃程度和文档完善程度，自己拍脑袋写的package直接跳过所有步骤不过99%是垃圾。

这帖子居然这么多页，果然喜欢玩游戏的大部分都是码农

看你回帖里说，JAVA处理高并发以及大数据，这些内容在我眼里就是头大象，用JAVA完全没错。

我想吐槽我们公司的渣渣Java的原因是，他们对http协议这种做web应用最基础的知识都掌握不牢固

这种反而不是大象，甚至可以说不是编码单方面的事情了

就是因为不只是编码所以选java更可能是对的，具体情况还是lz最清楚

所以我从来没有吐槽过Java语言不对啊，我也没吐嘈框架不好啊……
本来需求就只要切苹果，用Java做个切苹果小刀就行了，如果苹果变成了橙子，就在做一把切橙子的小刀就好了，本来种小刀Java做起来就很容易……
结果这帮Java开发上来非要上CNC机床，说这机床不仅能切苹果，还能切木头切铁，别说水果，宇宙飞船都能造，你还想着小刀，太low了……

所以我都懒的解释了……大家不是一个层面的……
越是要求高并发，高可用个，其实架构设计上来说就要越简单，更轻量！
说白了，高并发高可用背后不应该是一头大象，而是千千万万个蚂蚁！
做个蚂蚁搞那么复杂干叼啊……

看了下楼主的描述，感觉也没错，如果需求只是接收转发，并不需要一堆的框架，netty就够用了，只是现在的java开发大多都不会用netty,mina这些了，后期扩展维护什么的比较难。