最近,在看一本叫做”无印良品管理笔记”的书,结合之前看过的一本书”走出软件作坊”和自己现在的工作有一些自己的思考.特此记录.
本文的主要内容：
领导层的梦想，以及九大特点。
程序员的梦想，以及四大谎言。
三个不愿分离，三个不愿统一。
正是上面这些原因造成公司觉得程序员永远不够用。或者说,总觉得程序员与产出不成比例.科学技术是第一生产力，人不是！如果非要说人也是，那么只有掌握科学技术的人才是.
透过现象看本质。Java是企业应用市场的王者，如果一家非互联网公司用Java，那么十有八九是做企业应用的。所以，这个东西本质上是：为什么做企业应用的公司需要那么多Java程序员。开发企业应用的公司和程序员都有其自身的特点，分别展开说一下。
先说说做企业应用的公司,感觉下面九点不一定在所有公司身上都存在，但肯定是大同小异。只是角色的身份有所转变.
1.相对于互联网来说，企业应用不是一个公平竞争的市场。互联网公司创业之初往往是因为有好想法好技术，企业应用公司创业之初是因为老板有人脉有关系。大部分做企业应用的公司都是靠老板的人脉关系活着，靠在某个领域的关系垄断霸占着这块业务。而且也因为老板和高层习惯于人脉和关系，公司也会形成官僚国企文化，而不是工程师文化。所以这些公司技术老旧薄弱，技术人员也从来不会被重视。很多公司虽然有个高新技术认证，但根本没有任何技术含量可言。
2.甲方是老板的上帝，老板得罪不起，因为得罪了就自毁人脉和关系，就没有在这个行业立足之本。特别是行业圈子有限，客户之间都是有联系的，得罪一个就会传到别人那去。所以甲方可以蛮横的在需求、设计、技术方案等各种环节上提出自己的修改要求。而绝大多数甲方都是自以为是，什么都不懂，仅仅是为了表明自己懂或向领导证明自己懂。在项目实施过程中，和客户对接的程序员完全处于弱势。心中几万匹草泥马奔腾着，却要点头称是，敢怒不敢言。
3.有些甲方其实根本就不懂自己的行业，或者根本不能代表最终用户，不知道自己的需求到底是什么。往往就是一句话：你先做出来再说。所以无意义的需求变更过于频繁，甚至有可能彻底推翻重来。而且这些甲方都是恨不能XP用一辈子的人，他们见不得任何新颖的设计。比如你用了现代化的前端，他们反而不买账，就觉得老界面舒服。你用Spring Boot了，他们认为你连Tomcat都不知道，反而觉得你太Low。这就更进一步助长了公司内部一些不思进取的人，他们拿着尚方宝剑说：用户不认可这样！
4.项目招标同质化竞争，明着互相压价、暗着陪标围标等各手段都上。一家公司提出免费维护三年，另一家就可能提出免费维护五年。反正不管将来怎么样，先要把这个项目拿下来再说。最后项目工期可能是合同上的两倍，而且还要面临着验收后好几年的维护期。维护期往往就需要搭一个人进去，没有任何利润可言。最后造成项目整体式亏本，能收支平衡就不错了。
5.不像互联网应用那样，客户是网民，没有地域限制。企业应用的客户很可能不在公司本地。客户需要人员驻场开发才放心，我花了钱了就要见到你们的人，否则我怎么控制进度，我怎么知道你们是不是用最后两个月突击完成的。所以差旅住宿成本飙升。为了能有新项目收入，就必然不惜血本继续拿新项目。然后新项目又不断压价，造成恶性循环。
6.公司成立之初，可能有几个骨干技术人员。随着公司慢慢发展，他们就成了技术副总、技术总监、技术经理什么的技术管理层。但是这些人基本不会自我提升，而是想着如何继续把公司的技术把控在自己手里，让自己永远坐在过去的功劳簿上。所以他们就禁止技术升级，禁止他们不会的任何技术出现。这样他们才有用，他们才能管理新入职的程序员。
7.公司不重视技术，也就不重视技术人员。技术人员永远是三等公民，远没有销售的地位高，也不如财务、行政等职能部门那些会来事。程序员在项目的投标、实施的整个生命周期中没有话语权。投标时，销售为了中标就胡乱承诺功能和时间进度，根本不会和实际开发的技术人员商量。往往只是给技术总监打个招呼，而技术总监不会考虑底层程序员的利益。实施中，面对客户的需求变更，销售和技术管理层不会和用户讨论需求变更的原因和合理性，而是会配合用户软硬兼施让程序员去实现。
8.在企业应用的公司里，除了程序员以外，所有人对软件开发的理解就是堆代码搬砖头，人月神话在我们这里一次一次真实上演。一堆砖头，4个人6个月能搬完，6个人4个月也可以，上12个人就可以用2个月完成！所以从老板到销售到技术总监，一遇到进度问题首先想到加人。不管是需求的原因还是技术上的困难，能给我们加人就是对我们最大的恩赐。
9.为了降低人力成本，或许也为了让客户看到自己公司人多，所以就招聘低水平的研发。本来应该招聘一个两万四的，但更愿意招聘两个一万二的，最后招聘的是三个八千的。这些人谈不上架构水平、代码质量、自测什么的，造成项目交付质量极差，往往让客户充当了测试的角色。这就进一步让客户对公司产生怀疑，认为公司没有全力投入，更要求你驻场开发。
总之，所有的这些因素都在不断恶性循环。循环的结果就是：做企业应用的公司可能会发展变大，但是不会变强。变大是因为研发和后期维护人员摊大饼式扩展。不会变强是因为技术常年不会有任何变化，人员层次常年不会有任何提升。没有人从提升技术水平和开发效率的方向去考虑问题，都在想如何拿更多的项目、如何跟客户玩游戏。
每一个有点理想的做企业应用的公司或老板都有一个梦，就是产品化。说白了就是能把产品刻成光盘卖(当然这是传统的做法，现在网上下载也行)。因为只有这样才能突围出怪圈，走上由大变强之路。这需要公司有非常深厚的行业经验，了解用户的想法，抓住用户的痛点，从中总结和归纳出通用需求。需要有非常强的架构和设计能力，让产品可以按需裁剪、灵活定制。需要有非常强大的编码和测试水平，让产品能够稳定顺畅。为了能够实现产品化，但又要面对现有技术水平太差的现状，很多公司就采用项目养产品的策略。就是专门成立一个产品部门或团队，从其他项目组抽调技术人员，或者新招聘几个所谓的高手，集中力量研发产品。产品研发是一个周期长、成本高、风险大的工作，而且在真正出来满意产品前是不挣钱的，只能靠项目赚的钱来输血。这种策略往往都是失败的，因为没有一个初创公司有实力、有耐心去长时间养着一个不挣钱的团队。所以，几乎没有公司能实现这个梦想，都会重新回到摊大饼的老路上。
上面说的是公司，下面说说技术和技术人员.
我描述一个场景：有一个工地，几百号人在用铁锹铲子挖坑。我找上门去，问工头：你们知道有一种设备叫挖掘机吗的不知道，有的知道。有的以前在别的工地见过或开过，只是来这边以后没机会用了。如果我开一辆挖掘机来，用一天时间干的活就相当于你们这一个工人一个月的工作量，你相信吗更重要的是这个挖掘机是免费开源的，不用花钱买，仅仅需要学习掌握如何操作。这几百号人的工地就是企业应用项目开发实施团队。而我说的挖掘机就是新技术.
正像我上面场景里描述的那样，有很多技术负责人和普通Java程序员都知道新技术。但是对于他们来说有点遥远了，可望不可即。有的Java程序员自己在偷偷学，跃跃欲试，但是这种技术氛围的公司不可能给我们实践的机会。有的技术负责人也认识到了新技术能够为公司技术带来的提升，但是苦于自己也不会，更没有能力对下属培训和指导。如果新招聘会的人，自己连面试问什么问题都不清楚，又怕招聘来个水货。总之这些所谓的“新技术”对企业应用市场造成了一定的冲击，但企业自身却有各种困难无法把新技术转换成真正的生产力。
当公司有人(或请人)对团队进行一系列的培训和宣讲后，我们都会认同铁锹铲子和挖掘机之间的差距。这时程序员就会在内心深处面对另一个难题：破梦。什么是破梦是打破程序员的梦，把他们从舒适区赶出来。之前说过，每一个有理想的企业软件公司都有一个梦，就是产品化。而公司里的Java程序员也有一个梦，就是手头会的东西能用一辈子。自己永远待在思想的舒适区里，不想动脑子，不想转换思想，只想日复一日做重复的工作。有一句话是叫：没有公主命却有公主病，这里应该是：不是铁饭碗的命，却做着铁饭碗的梦。这个梦比公司的梦更容易实现，不用花一分钱，不用开一次会议。有适当的土壤和水分，种子就会发芽，而做企业应用的公司就满足这些条件。最最可怕的是，这个梦是集体的梦，而不是一个人的梦。如果只是一个人的梦，这个人会被淘汰。如果成为集体的梦就会开始逆淘汰，那些不断提高自己不断学习接受新技术的人会被“淘汰”。
加班愿意啊… 但可以接受！
出差愿意啊… 但可以接受！
薪资没有互联网公司高愿意啊… 但可以接受！
学习现在的主流技术栈，提升开发效率愿意啊… 不但不能接受，还有很多理直气壮的理(谎)由(言)拒绝你！
下面四个谎言就比较常见：
1.这个技术不适合企业应用！
说这句话的人，大部分认为某项技术只适用于互联网。他们简单的认为互联网和企业应用在开发上有很多不同，而很多技术天生就被打上了不同的标签。但实际情况不是。没有专为互联网应用开发的Spring Boot，也没有专为企业应用开发的SSM/SSH。没有专为互联网应用开发的React，也没有专为企业应用开发的Angular。没有一家互联网公司只有为普通用户开发的界面。滴滴不可能只有给乘客和司机用的两个App。阿里巴巴集团，上到马云下到普通员工，不可能成天顶着天猫和淘宝界面浏览。他们都有自己的中后台系统。蚂蚁金服的内部，也不是天天只访问支付宝界面。就蚂蚁金服的中后台系统复杂程度就不亚于一个国有商业银行，腾通的中后台系统绝对不会比电信的简单。
2.这个技术不成熟！
事实是他根本没有去深入了解这个技术。往往当他说完这话之后就不会再和我继续讨论了，他说这句话的同时就算是给我盖棺定论了。不成熟的技术，当然不在公司乱用，万一影响到项目进度和质量，谁能付得起责任不愿意花时间去深入了解一项技术，不勇于“试错”，有怎么知道这项技术不成熟呢了解的就是不成熟的，不成熟的就是不能用的，不去用就永远不了解。这个死循环永远打破不了。
3.这个东西太难用！
有些技术，因为他们听的太多了，耳朵都磨起茧子了。或者是别人强迫他们去学习了解的。当他们遇到一点点困难就甩出这句话，然后就没有然后了。软件开发首先是思想活动，其次才是敲代码。思想最难的就是转变。一个新技术或新框架，往往是因为旧技术或框架无法支撑其新的思想才出现的。或者说，新技术就是代表了新思想。技术的进步本质上就是思想的进步。可是有些人学习一个新东西，就是要往自己已经会的东西上套。套不上就是难用！可是完全套上了又和之前的东西有什么差别呢参加工作前，做了N多年“学生”，难道不就是学习“生”疏的东西吗习就是转变思想的过程。学习一个新技术新框架，就是跟着作者的思想在想问题。想明白想通了，处处顺风顺水。想不通，觉得别扭，开发也束手束脚。
4.这个技术对现状提升不大!
事实上,很多新的技术为了不断层都会对老技术,老框架有很大程度上的妥协.换言之,并不是所有人或公司敢进行断层式的更新或迭代.我们再替换技术时,更多的应该有长远的打算和考量.技术储备是一个老生常谈的问题.但我们意识到需要作出更改的时候再去变更.升级的成本往往要比之前更高.
回到前面说的铁锹铲子和挖掘机的话题上来。当有识之士意识到挖掘机对自己生产力会有变革性的提升时，他们就会在内心深处面对这样一个难题：公司内程序员的梦怎么破些理直气壮的谎言怎么才能揭穿br> 再说说三个分离,做企业应用的公司害怕分离，总以为都掺在一起才是最直接最省事的，分离就是自己给自己找麻烦，就是脱了裤子放屁。但事实是相反的。
1.前后端分离。老生常谈了，我自己都烦了。
2.人员分离。顾名思义,就是任务分离.上一家公司起家时是做日本一家公司的人力外包.听前辈说,每周一，日本人和他们视频会议，把这周要开发的任务讲解一下。如果有他们不懂的业务，日本人会给他们解释。他们要在周五下班前把本周开发并自测过的代码发给日本人。日本人利用周末的时间测试他们的代码。下一个周一会先把周末测试的结果给他们，然后继续讲这周的开发任务和业务讲解。他们先把测试的Bug改了，然后开发本周的功能。就这样循环滚动下去。前辈们没有从日本人那里学到什么Java编程技术，但是却在这种工作模式上深受启发。两组语言不通的人，隔着那么远的距离，仅仅靠翻译就能协同工作的如此顺畅。日本人把软件开发任务分解的非常合理，每一小部分的需求描述的非常清晰形象。就像流水线上的工人一样，前辈甚至无需知道最终生产出来的产品是什么样子，只需完成好自己这一道工序的操作就好。
3.环境分离。严格区分开发(dev)、测试(test)、演示模拟(staging)、产品(prod)环境。最低要求也应是分为开发、产品两个环境。对于我们而言,可能还有各项目地环境;
最后说说三个统一,做企业应用的公司也不愿意统一，总认为统一就是束手束脚，统一就是约束了自由意志，限制了个性的发挥。事实同样是相反的。
1.统一开发环境配置.公司应该给出一个明确的开发软件配置列表，包含用到的所有软件，以及他们的最低版本和基本配置。见过太多人把JDK或IDE装到类似 G:学习资料Java Project开发工具 这种路径下面。见过无数次“为什么在我这能跑，在你哪里就不能跑了”的怪现象。由于路径含有中文或空格引起的错误，由于安装路径和版本不同造成运行差异的问题，都屡见不鲜。
2.统一代码风格.这个就不说了吧，大家都知道，但是没有公司能做到位的。找一套编码风格规范很容易，但是让每个人都养成习惯太难，定期有人做代码复查就更难了。
3.统一组件库.公司内用什么第三方库，最好有统一的要求，需要升级的时候统一升级。
上面讲的害怕分离和不愿统一，总结起来的根源就是：习惯原始小作坊化、逆工程化。机械、建筑、纺织、电子、哪怕是某些国家的农业都早已进入了现代工业化大生产阶段。但是软件开发，特别是企业软件开发还将长期停留在小作坊阶段。什么是工业化大生产业化就是专业分离。一家大飞机的几万个零件，又全球不同国家不同企业研发制造。一个零件，要经过若干道复杂的工序才能出厂。你们不是号称自己精通业务吗们看看自己熟悉的行业是如何分工的。不分工明细，何来如此复杂的业务流程。工业化就是标准统一。只有标准集装箱，才能促进全球贸易往来。只有统一的铁轨才能让火车跑起来。只有统一的电压和频率才能让大家放心购买电器。
文中观点部分摘录自知乎陈龙老师在问题”为什么做企业应用的公司需要那么多Java程序员”下的回答.
文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91312 人正在系统学习中
来源：亖三二丶
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！