为什么做 Java 开发的公司需要那么多程序员？ 第1页

本来没想太认真回答这个问题，但是经过不断补充完善，现在已经超一万两千字了。有些描述不当的地方，还有拼音输入引起的错字，都请及时指正。有些文字可能比较偏激和悲观，但我的本意是希望能够唤醒那些做企业应用的公司和里面的Java程序员。

作为一个41岁的老码农，确实需要给刚入行的新人或者正在项目组迷茫的程序员交代点什么了。

本文的主要内容：

领导层的梦想，以及九大特点。

程序员的梦想，以及三大谎言。

三个不愿分离，三个不愿统一。

正是上面这些原因造成公司觉得程序员永远不够用。

科学技术是第一生产力，人不是！如果非要说人也是，那么只有掌握科学技术的人才是。

科学技术是第一生产力，管理不是！如果非要说管理也是，那么只有适应当前技术并能解放生产力的管理制度才是。

如果想学习Spring Boot和Typescript/Angular/React，可以加我微信:32698325。

最近搜我号的人太多，评论区有人反映搜索异常了。也可以先关注我的公众号：全栈通途

--------------------下面是回答--------------

透过现象看本质。

Java是企业应用市场的王者，如果一家非互联网公司用Java，那么十有八九是做企业应用的。

所以，这个问题本质上是：为什么做企业应用的公司需要那么多Java程序员。

开发企业应用的公司和程序员都有其自身的特点，我们分别展开说一下。

我们先说说做企业应用的公司

下面9点不一定在所有公司身上都存在，但肯定是大同小异。

1. 相对于互联网来说，企业应用不是一个公平竞争的市场。互联网公司创业之初往往是因为有好想法好技术，企业应用公司创业之初是因为老板有人脉有关系。大部分做企业应用的公司都是靠老板的人脉关系活着，靠在某个领域的关系垄断霸占着这块业务。而且也因为老板和高层习惯于人脉和关系，公司也会形成官僚国企文化，而不是工程师文化。所以这些公司技术老旧薄弱，技术人员也从来不会被重视。很多公司虽然有个高新技术认证，但根本没有任何技术含量可言。
2. 客户是甲方是老板的上帝，老板得罪不起，因为得罪了就自毁人脉和关系，就没有在这个行业立足之本。特别是行业圈子有限，客户之间都是有联系的，得罪一个就会传到别人拿去。所以甲方可以蛮横的在需求、设计、技术方案等各种环节上提出自己的修改要求。而绝大多数甲方都是自以为是，什么都不懂，仅仅是为了表明自己懂或向领导证明自己懂。在项目实施过程中，和客户对接的程序员完全处于弱势。心中几万匹草泥马奔腾着，却要点头称是，敢怒不敢言。
3. 有些甲方其实根本就不懂自己的行业，或者根本不能代表最终用户，不知道自己的需求到底是什么。往往就是一句话：你先做出来再说。所以无意义的需求变更过于频繁，甚至有可能彻底推翻重来。而且这些甲方都是恨不能XP用一辈子的人，他们见不得任何新颖的设计。比如你用了现代化的前端，他们反而不买账，就觉得老界面舒服。你用Spring Boot了，他们认为你连Tomcat都不知道，反而觉得你太Low。这就更进一步助长了公司内部一些不思进取的人，他们拿着尚方宝剑说：用户不认可这样！
4. 项目招标同质化竞争，明着互相压价、暗着陪标围标等各手段都上。一家公司提出免费维护三年，另一家就可能提出免费维护五年。反正不管将来怎么样，先要把这个项目拿下来再说。最后项目工期可能是合同上的两倍，而且还要面临着验收后好几年的维护期。维护期往往就需要搭一个人进去，没有任何利润可言。最后造成项目整体式亏本，能收支平衡就不错了。
5. 不像互联网应用那样，客户是网民，没有地域限制。企业应用的客户很可能不在公司本地。客户需要人员驻场开发才放心，我花了钱了就要见到你们的人，否则我怎么控制进度，我怎么知道你们是不是用最后两个月突击完成的。所以差旅住宿成本飙升。为了能有新项目收入，就必然不惜血本继续拿新项目。然后新项目又不断压价，造成恶性循环。
6. 公司成立之初，可能有几个骨干技术人员。随着公司慢慢发展，他们就成了技术副总、技术总监、技术经理什么的技术管理层。但是这些人基本不会自我提升，而是想着如何继续把公司的技术把控在自己手里，让自己永远坐在过去的功劳簿上。所以他们就禁止技术升级，禁止他们不会的任何技术出现。这样他们才有用，他们才能管理新入职的程序员。
7. 公司不重视技术，也就不重视技术人员。技术人员永远是三等公民，远没有销售的地位高，也不如财务、行政等职能部门那些会拍马屁的。程序员在项目的投标、实施的整个生命周期中没有话语权。投标时，销售为了中标就胡乱承诺功能和时间进度，根本不会和实际开发的技术人员商量。往往只是给技术总监打个招呼，而技术总监不会考虑底层程序员的利益。实施中，面对客户的需求变更，销售和技术管理层不会和用户讨论需求变更的原因和合理性，而是会配合用户软硬兼施让程序员去实现。
8. 在企业应用的公司里，除了程序员以外，所有人对软件开发的理解就是堆代码搬砖头，人月神话在他们这里一次一次真实上演。一堆砖头，4个人6个月能搬完，6个人4个月也可以，上12个人就可以用2个月完成！所以从老板到销售到技术总监，一遇到进度问题首先想到加人。不管是需求的原因还是技术上的困难，能给你加人就是对你最大的恩赐。
9. 为了降低人力成本，也为了让客户看到自己公司人多，所以就招聘低水平的研发。本来应该招聘一个两万四的，但更愿意招聘两个一万二的，最后招聘的是三个八千的。这些人谈不上架构水平、代码质量、自测什么的，造成项目交付质量极差，往往让客户充当了测试的角色。这就进一步让客户对公司产生怀疑，认为公司没有全力投入，就要求你驻场开发。

总之，所有的这些因素都在不断恶性循环。循环的结果就是：做企业应用的公司可能会发展变大，但是不会变强。变大是因为研发和后期维护人员摊大饼式扩展。不会变强是因为技术常年不会有任何变化，人员层次常年不会有任何提升。没有人从提升技术水平和开发效率的方向去考虑问题，都在想如何拿更多的项目、如何跟客户玩游戏。

多说两句：

我毕业19年，一半时间在开发企业应用的公司。经历过几百上千人的国企，也经历过十几个人的小私营公司。面对的行业有政府、电网、电信、民航等等。09年以前是Weblogic平台国内专家，后来主要是Spring+前端。现在还在给多家企业做技术咨询顾问，帮助他们整体技术提升。这19年，我从未见上面的恶性循环趋缓，而是还在不断恶化下去。

每一个有点理想的做企业应用的公司或老板都有一个梦，就是产品化。说白了就是能把产品刻成光盘卖(当然这是传统的做法，现在方网上下载也行)。因为只有这样才能突围出怪圈，走上由大变强之路。这需要公司有非常深厚的行业经验，了解用户的想法，抓住用户的痛点，从中总结和归纳出通用需求。需要有非常强的架构和设计能力，让产品可以按需裁剪、灵活定制。需要有非常强大的编码和测试水平，让产品能够稳定顺畅。

为了能够实现产品化，但又要面对现有技术水平太差的现状，很多公司就采用项目养产品的策略。就是专门成立一个产品部门或团队，从其他项目组抽调技术人员，或者新招聘几个所谓的高手，集中力量研发产品。

产品研发是一个周期长、成本高、风险大的工作，而且在真正出来满意产品前是不挣钱的，只能靠项目赚的钱来输血。这种策略往往都是失败的，因为没有一个公司有实力、有耐心去长时间养着一个不挣钱的团队。所以，几乎没有公司能实现这个梦想，都会重新回到摊大饼的老路上。

这几年一线城市生活、租房等成本飙升，而且必然会传导到程序员的薪资要求上。原来社保福利能不上的不上，必须上的按最低标准上。以后社保由税务部门统一征缴(现在暂缓实施)，那就逃不掉了。所以，最近几年会有大批做企业应用的公司裁员或完蛋。因为研发人力成本是公司经营成本中最大的一部分，这部分成本在加速上升。原来活的好的公司会面临巨大压力，原来活不好的公司会面临死亡。

本回答中的一些观点可以参考我之前的几个回答。

企业软件开发考古断代学：

三体智子理论：

上面说的是公司，下面咱们说说技术和技术人员

面对企业的负责人，我经常描述一个场景：有一个工地，几百号人在用铁锹铲子挖坑。我找上门去，问工头：你们知道有一种设备叫挖掘机吗？有的不知道，有的知道。有的以前在别的工地见过或开过，只是来这边以后没机会用了。如果我开一辆挖掘机来，用一天时间干的活就相当于你们这一个工人一个月的工作量，你相信吗？而更重要的是这个挖掘机是免费开源的，不用花钱买，仅仅需要学习掌握如何操作。

这几百号人的工地就是企业应用项目实施团队。而我说的挖掘机就是Spring Boot + 前端(Angular/React/Vue)，当然也就是我现在推广的JHipster。

正像我上面场景里描述的那样，有很多技术负责人和普通Java程序员都知道Spring Boot和前端框架。但是对于他们来说有点遥远了，可望不可即。有的Java程序员自己在偷偷学，跃跃欲试，但是这种技术氛围的公司不可能给你实践的机会。有的技术负责人也认识到了新技术能够为公司技术带来的提升，但是苦于自己也不会，更没有能力对下属培训和指导。如果新招聘会的人，自己连面试问什么问题都不清楚，又怕招聘来个水货。总之这些所谓的“新技术”对企业应用市场造成了一定的冲击，但企业自身却有各种困难无法把新技术转换成真正的生产力。

我会给一家企业介绍讲解现在主流技术栈，并且给他们的员工培训。还会让他们自己找一个典型的业务模块让我用新技术去重新实现，然后把新技术实现和他们以前老技术实现作对比讲解。这些过程完成以后，他们都会认同铁锹铲子和挖掘机之间的差距。这时他们就会在内心深处面对另一个难题：破梦。

什么是破梦？就是打破程序员的梦，把他们从舒适区赶出来。

之前说过，每一个有理想的企业软件公司都有一个梦，就是产品化。而公司里的Java程序员也有一个梦，就是手头会的东西能用一辈子。自己永远待在思想的舒适区里，不想动脑子，不想转换思想，只想日复一日做重复的工作。有一句话是叫：没有公主命却有公主病，这里应该是：不是铁饭碗的命，却做着铁饭碗的梦。

这个梦比公司的梦更容易实现，不用花一分钱，不用开一次会议。有适当的土壤和水分，种子就会发芽，而做企业应用的公司就满足这些条件。可怕的是，这个梦是集体的梦，而不是一个人的梦。如果只是一个人的梦，这个人会被淘汰。如果成为集体的梦就会开始逆淘汰，那些不断提高自己不断学习接受新技术的人会被“淘汰”。

在我见过的多家公司，这个梦已经实现了。

加班？不愿意啊... 但可以接受！

出差？不愿意啊... 但可以接受！

薪资没有互联网公司高？不愿意啊... 但可以接受！

学习现在的主流技术栈，提升开发效率？不愿意啊... 不但不能接受，还有很多理直气壮的理(谎)由(言)拒绝你！

下面三个谎言比较常见：

1，这个技术不适合企业应用！

说这句话的人，大部分认为某项技术只适用于互联网。他们简单的认为互联网和企业应用在开发上有很多不同，而很多技术天生就被打上了不同的标签。但实际情况不是。

没有专为互联网应用开发的Spring Boot，也没有专为企业应用开发的SSM/SSH。没有专为互联网应用开发的React，也没有专为企业应用开发的Angular。

没有一家互联网公司只有为普通用户开发的界面。滴滴不可能只有给乘客和司机用的两个App。阿里巴巴集团，上到马云下到普通员工，不可能成天顶着天猫和淘宝界面浏览。他们都有自己的中后台系统。蚂蚁金服的内部，也不是天天只访问支付宝界面。

就蚂蚁金服的中后台系统复杂的就不亚于一个国有商业银行，腾通的中后台系统绝对不会比电信的简单。

最近在给多家企业推广Ant Design。当然们看到Ant Design文档中这段话时，深表认同：

蚂蚁的企业级产品是一个庞大且复杂的体系。这类产品不仅量级巨大且功能复杂，而且变动和并发频繁，常常需要设计与开发能够快速的做出响应。
从 2015 年 4 月起，Ant Design 在蚂蚁金服中后台产品线迅速推广，对接多条业务线，覆盖系统 800 个以上。

有做企业应用的公司有800个系统吗？蚂蚁金服的中后台产品线有，而且还仅仅是已经推广了Ant Design的。

2，这个技术不成熟！

事实是他根本没有去深入了解这个技术。往往当他说完这话之后就不会再和你继续讨论了，他说这句话的同时就算是给你最盖棺定论了。

不成熟的技术，当然不在公司乱用，万一影响到项目进度和质量，谁能付得起责任？

不愿意花时间去深入了解一项技术，不勇于“试错”，有怎么知道这项技术不成熟呢？

就像我在这个回答中说的一样：

不了解的就是不成熟的，不成熟的就是不能用的，不去用就永远不了解。这个死循环永远打破不了。

3，这个东西太难用！

有些技术，因为他们听的太多了，耳朵都磨起茧子了。或者是别人强迫他们去学习了解的。当他们遇到一点点困难就甩出这句话，然后就没有然后了。

在我的多个回答里，反复强调一句话：软件开发首先是思想活动，其次才是敲打吗。

思想最难的就是转变。一个新技术或新框架，往往是因为旧技术或框架无法支撑其新的思想才出现的。或者说，新技术就是代表了新思想。技术的进步就是思想的进步。

可是有些人学习一个新东西，就是要往自己已经会的东西上套。套不上就是难用！可是完全套上了又和之前的东西有什么差别呢？

我们在参加工作前，做了十几年“学生”，难道不就是学习“生”疏的东西吗？学习就是转变思想的过程。学习一个新技术新框架，就是跟着作者的思想在想问题。想明白想通了，处处顺风顺水。想不通，觉得别扭，开发也束手束脚。

回到前面我们说的铁锹铲子和挖掘机的话题上来。当企业负责人意识到挖掘机对自己生产力会有变革性的提升时，他们就会在内心深处面对这样一个难题：公司内程序员的梦怎么破？那些理直气壮的谎言怎么才能揭穿？

下面回复评论区的一些观点

回复评论区 @井田 和 @契蛾 ：

莫名其妙的回答。企业软件要的是业务，根本不是开发技术，国内用友、金蝶等公司用java开发的erp只能在外围当做数据字典使用，真正下到生产实际中连20多年前的pb开发的程序都替代不了。
企业应用场景 技术从来不是重点。

这是企业软件行业常见的谎言和借口之一。企业应用就是面向某个特定行业开发定制化的软件，所以关注业务很重要，这个没错。但并不是说根本不是开发技术，或者技术从来不是重点。

我本文说要用新(其实一点也不新，而是主流，只是对于某些公司来说永远新)技术，目的不是替代20年前的程序，而是提高企业自身的开发效率，并且降低成本。

我们就不说新技术能够给开发带来多少便利，能够让原来无法实现或很难实现的需求变得多么容易，能够让用户体验度提升多少。这些都属于你给一个没见过电的人描述电能如何改变生活一样，他始终认为蜡烛和煤油灯能满足自己的需要。我们下面单从很多公司能否活下来这个角度看看技术的重要性。

一家企业软件公司，技术人员占比多大？一个有三五年经验的Java程序员薪资是多少？五到十年所谓老Java开发薪资是多少？本公司的行政、财务、市场等职能部门的人干到退休可能都拿不到他们现在的薪资。所以，在一家企业软件公司，技术人员的薪资是人力成本的大头，绝对的大头。因为他们人数占多，平均薪资又高。

如果我通过技术升级能让一家企业软件公司的研发人员数量减少一半，同时效率提升一倍，你觉得企业老板乐意吗？当然乐意，而且是梦寐以求的。一个薪资是一万五的程序员，社保和各种福利算上，企业实际承担两万。开源节流，省下来的钱也是钱。这还不算由于人员减少一半带来的水电、租用办公面积减少等的费用节约。

事实上可以做到通过技术升级，让企业软件公司的研发数量减少一半，同时效率提升一倍吗？通过我这几年的经历证明是可以的，而且这个目标还是保守的。

所谓的技术升级，不仅仅是从现在企业软件公司万年不变的JDK6 + SSH/SSM + JQuery/LayUI + MyEclipse升级到Java 8 + Spring Boot + Angular + IDEA。而是整个软件开发流程、思路的改变，是整个软件开发观念的改变。

就好像我上文描述的场景。并不是从铁锹铲子换成挖掘机就完事了，而是由于挖掘机等现代化作业设备的出现，改变了施工的工序和管理制度。对于开发企业软件的公司来说，开发思想和理念的升级，比纯粹升级换代技术要更难！

在做企业应用的公司，经常有人“语重心长”的说业务才是最重要的。仅仅是因为他们感觉自己略微比别人多一点行业经验而已，我跟你比不了技术，我在这家公司多待了几年，比你接触业务多，我就和你比这些。每个公司确实都需要行业专家、领域专家，但是这些懂业务的专家应该和技术分开。他们只需要用自己的经验和用户沟通，然后用文档清晰明确的描述需求，而实际情况是项目经理要求既懂业务又要带头干活。业务和研发的分开，才能保证业务更精通与业务而不被技术所累。才能保证技术人员的正常流动，避免去别的行业又不熟悉业务，只能受困于一个行业。

经常有人在知乎上抱怨“面试造火箭、入职拧螺丝”。我不相信那些能懂Java底层虚拟机、多线程，能搞清楚Spring的IoC、依赖注入、分层结构，能搞清楚各种算法的程序员搞不明白那些业务。仅仅是他们不想把时间和精力用在业务上，他们觉得自己不会长时间在这个行业干，技术才是能带走的东西，业务会扔在老旧的项目里一起埋葬。他们会买一本Java的书看，会买一本前端的书看，会买一本算法的书看，会上知乎提技术问题，哪怕会上CSDN翻翻博客也好，他们绝不会花时间主动去研究业务！

回复评论区 @lzclong：

企业应用里面技术要为业务服务，就像你自己说的技术的升级换代能节省企业成本改变企业文化，但是确实很难苟同你所谓的“技术才是能带走的，业务会随着老旧的项目一起埋葬”。试问不懂核心业务，你怎么判断所谓的多线程设计是不是合适？片面的割裂技术与业务的思路都是不可取的。
同意你的让业务和技术更专业。
但是在一家专注做企业应用的公司里面，80%的团队成员不能仅仅把自己定位于技术人员，技术人员不吃透业务应用场景，基本上都会陷入老虎吃天无从下口或者不负责任制造无用、低效率代码的地步。 纯技术人员从来都是那20%（或者更低比例）的金字塔尖的一波人。

昨天晚上花了好长时间回复你，可是睡觉了才发现内容没有保存上。现在重写。

我没有否定业务的重要性，我也同意要有吃透业务的人。我的观点是分离，不是分割。分离是让业务专注于业务，让技术专注于技术。

业务人员甚至可以不是计算机专业的，甚至可以不会编程。他们可能是行业内对口专业的，也可能是在行业内深耕多年积累丰富经验的，也可能是行业内退休的专家被聘来做业务分析和指导。

在项目初期，主要是业务人员在分析和分解业务，最终的成果就是设计文档。设计文档能够让技术人员纯粹用技术的视角就理解任务就知道该如何去实现功能。当然肯定不会这么完美，这就需要业务和技术的交流。

就像前后端分离一样。服务器端不用JSP了，并不是说没人负责界面和用户交互了，而是由更专业的前端框架完成这部分功，然后前后端分工配合实现整个应用。

我刚毕业的时候，2001-2003年做过两年对日外包。那时候还没用上Struts，就是纯JDK1.3 + JBuilder + JSP/Servlet。每周一，日本人和我们用Yahoo! Messenger 视频会议，把这周要开发的任务讲解一下。如果有我们不懂的业务，他们会给我们解释。我们要在周五下班前把本周开发并自测过的代码发给日本人。日本人利用周末的时间测试我们的代码。下一个周一会先把周末他们测试的结果给我们，然后继续讲这周的开发任务和业务讲解。我们先把测试的Bug改了，然后开发本周的功能。就这样循环滚动下去。

我没有从日本人那里学到什么Java编程技术，但是却在这种工作模式上深受启发。两组语言不通的人，隔着那么远的距离，仅仅靠翻译就能协同工作的如此顺畅。日本人把软件开发任务分解的非常合理，每一小部分的需求描述的非常清晰形象。就像流水线上的工人一样，他甚至无需知道最终生产出来的产品是什么样子，只需完成好自己这一道工序的操作就好。这就是任务分解，而任务分解的前提是设计清晰，能够细化，能够形象描述。

对日外包前，我已经考取了SCJP(Sun Certified Java Programmer)。对日外包做完以后，我认为架构和设计能力很重要，所以自己又学习并考取了SCEA(Sun Certified Enterprise Architect)认证。在SCEA的学习过程中，我发现UML不就是业务和技术之间的桥梁吗？UML就是让不懂编码的人能够通过图形的方式分析业务，然后清晰明确的描述业务。

UML里面的图形分成两类吧(Structural UML diagrams和Behavioral UML diagrams)。其中Behavioral UML diagrams里面的Activity diagram、Sequence diagram、Use case diagram、State diagram等等，不就是让不懂开发的人分析、描述、确定业务的吗？Structural UML diagrams里的Class diagram、Package diagram、Object diagram等等才是懂面向对象概念的程序员用的啊。

后来我开始接触Weblogic Platform，对Server、Portal、Integration都熟悉了，后来进一步熟悉了Weblogic Aqualogic。发现BPMN图形语言更丰富，更适合描述复杂业务流程！

之前我举了一个流水线的例子。我再举一个例子。某建工集团的工人。这个建工集团总包了一个普通居民楼的工程，这些工人去了能建造出一栋栋居民楼来。下次这个建工集团可能会总包一个鸟巢水立方的工程，还是这些工人去了能把鸟巢水立方建出来。再下次，如果他们去建造大裤衩，还是能完成任务。这其中的关键在于设计能力，以及设计的层层细化能力，是一个产业成熟的标志。绝对不会要求每名工人既懂居民楼的业务，还要懂最现代化的体育场的业务。当然，你也会经常见到有设计师对着图纸在施工现场。当然，鸟巢水立方引入了很多最新施工工艺，需要对工人做一些特殊说明。这就是我之前说的业务和技术之间需要配合和交流。

UML图和专门用来分析复杂业务流程的BPMN都是行业标准了，但是却被我们搁置在一边。让每名工人都既懂得设计和建造大裤衩有能设计和建造普通居民楼。要么你的职业生涯就老老实实困在我这里建造居民楼，去别的地方你不懂业务。这写都是产业不成熟的表现。

说到分离，再多说几句。

做企业应用的公司害怕分离，总以为都掺在一起才是最直接最省事的，分离就是自己给自己找麻烦，就是脱了裤子放屁。但事实是相反的。

我现在能想起三个层面的分离，很多数公司都不能同时做好。能实现一个层面的分离已经是难为他们了。

1，前后端分离。老生常谈了，我自己都烦了。不多说，多看看我其他相关回答。

2，人员分离。上面讲的就是，但不仅仅局限于此。还应该包括前端人员、服务器端人员、测试人员等等的分离。往往在一家公司，业务、(如果分前后端的话)开发、测试都是一同组人。

3，环境分离。严格区分开发(dev)、测试(test)、演示模拟(staging)、产品(prod)环境。最低要求是分为开发、产品两个环境。

充分利用Spring的指导思想和提供的特性，分成application-dev.properties(yml)和application-prod.properties(yml)两个配置文件。

比如我就禁止研发人员在自己的电脑(尤其是笔记本)上装数据库。因为这台机器是开发环境，有H2这类专门用在开发环境的数据库呢。见过太多程序员把Oracle、SQLServer装在自己的笔记本上，然后成天喊太卡，要求公司加内存。

最后的所谓发布和部署，就是把笔记本上的代码复制一份到客户服务器的Tomcat下。简单、省事、一步到位，这就是我们企业应用开发最聪明之所在。

现在的前端开发也要用webpack配置开发和产品，开发环境方便调试、热加载、测试，产品环境会优化、混淆、压缩。从开发到产品要npm build一下，这让企业开发的人觉得不可思议。干嘛要这么复杂？不就写个JS吗？

做企业应用的公司也不愿意统一，总认为统一就是束手束脚，统一就是约束了自由意志，限制了个性的发挥。事实同样是相反的。

我现在能想起三个层面的统一，也没有企业能够都做好。

1，统一开发环境配置

我曾经写过一篇文章，介绍Chocolatey：

公司应该给出一个明确的开发软件配置列表，包含用到的所有软件，以及他们的最低版本和基本配置。其实现在的Java服务器端开发机器只需要JDK和IDE就可以了，不需要安装Tomcat、Maven、数据库。可以参考我这篇文章：

见过太多人把JDK或IDE装到类似 G:学习资料Java开发工具 这种路径下面。见过无数次“为什么在我这能跑，在你哪里就不能跑了”的怪现象。由于路径含有中文或空格引起的错误，由于安装路径和版本不同造成运行差异的问题，都屡见不鲜。

在这些统一的基础上，其他可以自己定制。例如你喜欢暗色编辑界面，他喜欢亮色编辑界面。因为这些不会影响到开发。

2，统一代码风格

这个就不说了吧，大家都知道，但是没有公司能做到位的。找一套编码风格规范很容易，但是让每个人都养成习惯太难，定期有人做代码复查就更难了。

3，统一组件库

公司内用什么第三方库，最好有统一的要求，需要升级的时候统一升级。

前端用jQuery、Underscore/Lodash，要求统一到什么版本。用了Select2/Chosen，需要用某一个版本。等等不再例举。当然如果用现代化的前端开发，比较容易用package和package-lock统一版本。服务器端最好有自己的Maven库，用Nexus很容易就能搭建。

上面讲的害怕分离和不愿统一，总结起来的根源就是：习惯原始小作坊化、逆工程化。机械、建筑、纺织、电子、哪怕是某些国家的农业都早已进入了现代工业化大生产阶段。但是软件开发，特别是企业软件开发还将长期停留在小作坊阶段。

什么是工业化大生产？

工业化就是专业分离。一家大飞机的几万个零件，又全球不同国家不同企业研发制造。一个零件，要经过若干道复杂的工序才能出厂。你们不是号称自己精通业务吗？你们看看自己熟悉的行业是如何分工的。不分工明细，何来如此复杂的业务流程。

工业化就是标准统一。只有标准集装箱，才能促进全球贸易往来。只有统一的铁轨才能让火车跑起来。只有统一的电压和频率才能让大家放心购买电器。你们不是号称自己精通业务吗？你们看看自己熟悉的行业都有多少标准！我经历过国家电网、电信、民航等行业，标准繁多啊。

回复评论区 @还是无聊的人：

做企业应用的人到现在的习惯思维还是JSP，不让用JSP了就想到Thymeleaf，反正思维总是局限在服务器端。而我们必须要认识到，以前前后端分离是一种选项，今后前后端分离则是必须。更多观点看我的这个回答：

因为企业应用脱离不了Spring，不管现在是SSH还是SSM都在Spring的体系内，下一步升级也必然不会脱离Spring生态，而Spring Boot是必然的选择。Spring Boot是Spring现在最重要的项目，也是Java服务器端近些年唯一跟上时代的亮点。更多观点看我的这个回答：

Spring Cloud也是构建与Spring Boot之上的，所以Spring Boot是今后架构迁移到微服务的必由之路。更多内容看我这个回答：

Spring Boot本身对JSP就有一定的限制，当架构迁移到Spring Cloud的时候，JSP就彻底无用了。因为所有的前端都必须发送AJAX请求给Spring Cloud的API Gateway。

所以，以前用SSM/SSH，JSP是主流，前后端分离是可选。用Spring Boot，前后端分离应该是首选。用Spring Cloud，前后端分离是必须！

回复评论区 @moshanglalaxy :

刚开始读前面我一直以为我就是这种陈旧的人，后来你说挖掘机是springboot？.....我居然这么先进了吗

如果Spring Boot是挖掘机的话，那仅仅是挖掘机。现代施工作业不仅仅靠挖掘机，还有很多工程机械合使用，搅拌机、打桩机等等。

所以前提是Spring Boot这个的挖掘机要使用正确。不能开着挖掘机心里想着铁锹的操作要领。就像我上面回复评论区中说的，用Spring Boot还在想JSP或其他模板语言，否则就不会用了。

其次，Spring Boot要和前端框架配合好，利用好REST API，做到前后端分离的开发。而且为将来有可能的微服务迁移做好准备。

Spring Boot解决了服务器端各种框架的集成配置问题，而JHIpster包含Spring Boot，并给你了前后端最佳搭配的样板。

回复评论区 @黄浩：

做企业应用的公司永远谈不上技术，所有的技术都是在迫不得已的情况下被动的接受。为什么Struts2换成SSM？还不是因为现在用Struts的人太少了，不好招人了。培训班都已经不教了Struts了，而是以SSM为主了。喜欢技术、乐于创新的人在这样的公司永远不会发挥自己的优势。项目经理其实就是比别人多几年经验更懂一点业务，然后顶着个“经理”的头衔带头干活的。

所以，认清了环境后就要分析自己，你适合做技术还是适合混体制。喜欢论资排辈、温水煮青蛙、技术十年如一日，那就好好混。否则，趁年轻多学技术，找机会换环境。

我的一些相关文章和回答

想学习Spring Boot和前端开发的同学，看我的文章：