太多这种例子了，老板们早上出的新想法，恨不得第二天就能上线。。每个互联网公司都试图突破固定领地，不断地尝试新的业务，一旦发现不行，就立刻砍掉，名曰“试错”。

研发部门，为了应对压力，必然采用大军团作战的开发方式。打个比方，一个 6000 的项目

• 10 个人，每人效率 10，要 2 个月完成

• 而 100 个人，每人效率 5，只要 12 天完成

当然，这 100 个人的薪资成本肯定远高于这 10 人，但是公司不缺钱，更看中 2 个月变半个月的时间效率提升。在激烈竞争下，晚一天都会导致产品处于下风。

为了让大军团作战成为可能，公司的软件开发流程和工具，把程序员打造成螺丝钉和流水线工人，让人员充分的可替代。同时，公司对程序员的个人能力要求并不高。即使面试的时候被考核到的知识面很广很深，但是实际工作中，由于只负责很小的一块，导致每天就是拧螺丝。

对于技术管理者，也看中他的团队协作能力、向上汇报能力，而技术实力的比重越来越小。毕竟管理 10 人团队，还是要自己参与研发过程的，而管理 100 人团队，参与研发已经不可能了。

上述现象出现的根本原因，就是整个行业资金充裕，不需要自己盈利。如今，风口已经退去。互联网用户增长已经到顶峰，几乎所有能被互联网渗透的行业都被渗透，更关键的，获取风投、赴美上市的路子走不通了。所有的软件公司又要重新回到靠自己造血养活自己的正常商业模式。

风口过去了，资金没有那么充裕了，竞争也将逐渐缓和。大军团软件开发模式也难以继续下去，必然引发各大公司裁员，逐渐把大军团，缩减成小规模软件开发团队。人少了，但是要做的事情并不会等比例减少，为了应对这种情况，提升研发人员的个人能力成了必然的趋势。

低能力的程序员们应该尽早考虑逃离程序员行业，还在行业内混的程序员们，要不断提升个人的软件研发能力，来应对市场的变化。公司的用人理念也必将被迫转向更看中程序员个人能力。原本那些靠善于写 PPT，搞向上汇报，实际和研发脱节的管理者们，就业面越来越窄。

软件的内在质量，是用户看不到的质量，比如易读性、易测试性、易扩展性等。大军团作战时，由于团队总体水平低下，又特别赶时间，导致只要软件功能正确性能满足要求，就交付给用户了，没有多少时间去打磨软件的内在质量，代码逐渐变成屎山。屎山的后果是维护和再开发的成本越来越高。

由于有风口的加持，人力成本似乎都不是问题。等到屎山终于要倒塌了，出来一批勇士重写系统，再竖起一座新的屎山也就是了。这样的事情，在我过去十几年的从业经历中，不断重现。

哪些有益的实践要被重新重视起来？

比如，朴实实用的软件架构，而不是一味追求分布式微服务等高级架构。过往，有多少采用分布式微服务架构的系统，是因为真的有伸缩需求，真的基础设施能力达到了？我想有一大批只是为了向上汇报显得高大上吧？也有一些，单纯是因为团队太大，想借助分布式达成模块化，以符合康威法则吧？过往的经历中，大部分的微服务都是一场灾难。原本 IDE 内代码分析就可以掌握的代码依赖关系，必须依赖运行时的监控系统，原本 IDE 内一键重构的事情，必须变成线上灰度热替换，原本简单的上线步骤，变成复杂的分批上线。程序员为此加班掉头发，整个社会则为此浪费钱财。

​

再比如敏捷开发，大军团下，几乎没有全职能团队，部门墙，团队墙耸入云霄。敏捷开发的根本就是以人为本，近几年，在技术领域低代码是比较热门的话题，通过低代码工具，自动代码生成和可视化编程，只需要少量代码，即可快速搭建各种应用。

应用入口：JNPF快速开发平台（http://www.jnpfsoft.com?csdn），找个有空的时间自己试试！除了低代码工具，其他工具我在以往的文章中都有提到，你可以自己看看。

如今，风口过后，该重新关注软件内在质量了，留下来的公司们，该调整用人策略了，留下来的程序员们，该重视提升自身的研发能力了。