写代码之前应该做的几件事

作者：borisyang，腾讯 WXG 应用开发工程师

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

1 研发环境日益成熟

经历过 PC 互联网的不断深入发展，移动互联网的蓬勃生长，互联网进入了成熟繁荣期，研发环境也发生了巨大变化；从原来一个人，一把键盘，写完代码就上线，变成了更加规范的研发体系和更多人参与的共同协作。

研发流程不断加速

为了尽可能提高需求交付速度，跟上市场的变化，我们通过不断提搞软件交付的速度，尽可能的，从需求，编码实现，测试，发布的流程中不断优化，利用 CICD，加速迭代。

多人协作无处不在

现在的软件开发团队，即使再小，也有 2-3 人一起研发，更别提测试，运维，运营，产品人员。一方面是软件产品的竞争日趋激烈，需求日益复杂，堆砌人力成了必然；另外一方面是专业性的要求，精密的行业自然要求精细化的职业划分。

2 困局

研发流程的速度提上去了，团队的人也变多了，但是，需求变更依旧让广大研发同学感到痛苦，项目质量还在日益变差。

需求变更之痛

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

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

项目质量变差

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

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