新人接手老项目，总是要吐槽代码垃圾，然后向上级反馈：希望项目推到重来，在新的一片处女地上另立山头，彻底摆脱历史包袱。
其实这是一项风险很高的任务。
为什么代码如此糟糕？
很大一部分原在于，我们不喜欢阅读别人的代码，这项活动相对烧脑，代码逻辑纵横，加上背景信息缺失，大脑很快线程不够用，抓到一个不够优雅的地方，就立马对整体下定结论：这项目代码真烂。
对着老项目的迭代，人员流失，确实会出现代码腐败的情况，新人在老代码基础上纵横交错，难以维护；而从另一个角度，这些烂代码恰恰是经历过实战检验，至少是不会出错的代码。这层价值最易被忽视。
举个例子，我们经常看到又臭又长的函数，里面云里雾里包含了太多逻辑，当仔细挖掘每一段代码，通常会发现：a 是为了修复某个漏洞，b 是为了兼容某个系统版本，c 是修复了一个极端业务场景下的 bug，如此依赖，这是一个经验满满、抗住了各种意外情况的函数。
那么，现在你还确认你能重构一版更加完美的代码吗？
风险之源
重构的风险之源往往来自以下几个方面：
忽略太多历史情况
可预料的情况是：你快速奔跑的一口气完成了 80%，代码简洁优雅，一切都是那么的清晰，个人也成就感爆棚；测试阶段，忽然发现几个意外情况，开始丰富业务逻辑，上线后有陆续修了几个极端场景下的问题，最神奇的是，你想到了之前烂代码中也有类似的表述逻辑，忽然意识到了什么，最后几个版本迭代下去，新代码也成了别人口中的烂代码。
忽略发版周期
软件开发一项默认小步快跑，甚至以周为单位做版本迭代，如果有 6 个月+的大周期任务排期，那么实际情况很可能要一年，加上最后的测试验收，团队 bug 层出不穷，实际可交付的日期将永远延期。
如果一个软件产品一年没有发版迭代，这意味着什么？市场占有率直线下降，被竞争对手赶超。最后在收尾阶段匆忙发布一个 bug 重重的产品，本想震惊四座，却因各种问题被用户吐槽，简直是一场灾难。
新老项目双跑的陷阱
线上运行的项目，必然要各种迭代维护，我还没见过可以对外扬言封版不迭代的产品，这等于宣布下线，即使不研发新需求，也会有这种 bug、兼容的迭代开发，我们可以限制自己的版本不升级，但无法限制整个系统、所依赖的基础库不升级，加上依赖的基础库时不时的有漏洞修复和断崖式升级，自己的项目根本无法封版，总要有写需求改动。
这将面临一个新老系统双跑的问题：新的需求改动，老系统做一份，新系统也要做一份，原本计划可以突击完成的人力，再次被消减，重构周期继续被延长，在延长过程中，继续迭代老项目，直到新项目经历层层补丁，彻底补齐老项目能力，算下人力成本，比预期至少翻两倍。
如何避免
老项目烂代码越来越多，维护成本也越来越高，难道真的要任由发展？如何避免代码腐败？ 答案是悲观的：我们无法阻止代码的熵增，尤其是在业务驱动的公司。
有幸的是，我们可以无限延期代码腐败的速度，让原本三年就腐败的项目，时刻保持易维护的状态，这将在下篇文章中做进一步说明。
文章题图：你懂得
