作为程序员，刚刚开始学会写代码，常常是接过需求就开始撸代码。有时候发现，写完代码，需求变了。更多时候，觉得写业务代码枯燥无聊，没有技术含量。另外一边的事实却是，项目里面研发人数变多了，项目的质量缺却变低了，多人开发也不过是一个个单打独斗的组合而已。

1、需求变更之痛

需求变更的痛苦为难了广大研发同学，前脚刚为了优化性能，采用了 kv 存储，后脚需求就变成了要支持模糊查询；这是一种典型的架构设计不合理，导致业务需求的实现方式受限。

更令人痛苦的，还有产品需求变动多，今天简单实现下，上线看看效果，明天用户脾气很大提了个诉求，再加一个功能上线，产品功能变成补丁加补丁。一方面是研发同学渴望一个完整又严谨的需求，提完需求进入研发阶段就不许改；另一方面是产品同学受到各方面的压力，只希望先把主要问题解决下，细枝末节以后再说。

2、项目质量变差

项目质量变差，一部分归功于补丁代码的产生，迫于时间受限，先上一个补丁，却打开了破窗的先锋，下一次，下一个同学就更敢于加补丁代码。一个个临时的 if else 不断堆砌，最终导致了整个项目的代码腐烂。我曾经维护过一个代码片段，超过 20 个 if else，中间还有些过时的错误注释夹杂其中，维护起来令人苦不堪言。

项目代码腐烂的另外一个原因是多人协作，团队的人越多，代码反而变得越烂似乎成为了趋势；为什么多人协作没有提高代码质量呢？一方面，多人协作实际上只是分摊的需求实现而已，大多数需求实现的分配中，反而尽可能将协作变少，避免实现受阻。另外一方面是，不同人的代码模块，设计意图和代码风格也截然不同。维护前人代码，如果没有全局视角，了解设计意图，也只能是往里面加补丁代码了。

项目代码腐烂容易导致程序员出现错觉，一是业务代码没什么料在里面，不如搞基础建设；二是业务需求不可能完整又严谨，最终也会变来变去的，最终质量低下的锅，一大半要给提需求的人。