整理 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

讲道理，许多做过代码届“接盘侠”的程序员们，某种程度上可能十分理解电影中执着于毁灭世界的反派：“与其在现有基础上修改，还不如直接把这堆祖传代码毁灭再重建！”

祖传代码，从字面意思来看，就是一代代老程序员们留下来的“宝藏”代码——这些长年累月的代码中存有很多隐患，后来的“接盘侠”们要么无从下手，要么一改就崩，几乎可以说是程序员们的“终极噩梦”，因此也被称作“屎山代码”。

这不，最近又有一个“倒霉蛋”火上了 HN 热榜：“我继承了我见过的最差的代码和技术团队，该怎么办？”

拥有 12 年历史、没有版本控制的“祖传代码”

从这位“接盘侠” @whattodochange 阐述的现状来看，他这次继承的代码历史长达 12 年，是没有版本控制的 PHP 代码，居然每年还能产生超过 2000 万美元（约人民币 1.4 亿元）的收入：

以上就是 @whattodochange 目前所接盘的代码和团队现状，他头疼道：“我必须要找到一个策略来修复这个开发团队。”

面对这个“烂摊子”，@whattodochange 想到的解决办法是完全重写，但由于公司管理层和总部对这些阻碍因素并没有真正了解，业务部门对这个项目有非常积极的规划路线，且疫情之下公司的预算很紧张，导致 @whattodochange 根本无法推进。

因此，@whattodochange 发帖求助：“我知道完全重写是必要的，但要如何平衡？”

逐一改动 or 摆烂跑路？

对于 @whattodochange 的遭遇，不少有经验的程序员深有同感，也提出了一些应对“祖传代码”的具体建议。

“完全重写不是必需的，甚至可能是最糟糕的方法。可以一次做一件事，最终你会重写所有代码，但永远不会陷入‘完全重写’的陷阱中。 不过在重写一行代码之前，记得要做大量的测试。如果有端到端测试，这些测试运行在客户群当前使用的每个功能中，那么您就有一个基线来安全地进行更改。只要测试通过，就可以删除代码。 不要想着去推动变革，尝试拥抱这个每年赚 2000 万美元的可怕代码库，和团队讨论讨论如何在能力范围内改进即可。”

作为这个开发团队的经理，你的任务是要得到高管支持来逐渐解决这个烂摊子。你没必要告诉高管或团队具体要如何修复，只要有时间和空间上的支持就好。 有一种办法是每周五集合团队一起来测试，但可能会经常被紧急任务挤掉；另一种办法是让每个更新的发布速度稍慢一些，这样就有时间优化每次更新所涉及到的其他代码。例如，业务要求添加功能 X，那么你就给相关的现有功能 Y 添加一个测试，可以对团队说优化 Y 是为了让添加 X 更为方便。”

不过，也有部分程序员在了解 @whattodochange 的现状后，认为“摆烂跑路”是最优解：

“你应该考虑辞职。虽然你知道这代码很烂，但它确实能带来每年 2000 万美元的收入，所以你的团队不想变革，业务人员也不会关心代码质量。他们会认为：反正 2003 年样式的 PHP 代码就可以实现这个收入，那不挺好，干嘛要浪费财力和精力去重写？ 最后，你很难说服你的开发团队和业务部门同意重写这个决定，甚至还会招来仇视，而你自己也会讨厌这样的工作氛围。”

“为了避免自己受伤，我劝你摆脱这种混乱的处境。我之前也一直处于类似的情况，花了快五年的时间试图解决，但最后还是心累地放弃了。”

血泪教训：“人跟代码有一个能跑就行了”

其实在现实中，几乎所有软件开发公司都有各种老大难的“祖传代码”，像 @whattodochange 遇到这种 12 年历史的都还算年轻的了——一般越大规模越厉害的公司，“屎山”代码的情况越严重。

类似地，国内也有许多程序员分享过他们遇到的各种“骨灰级”祖传代码：

可能对于很多刚工作的萌新程序员来说，看见这些各处都埋着“地雷”的代码第一反应就是“推倒重来”，但大多都得到了血泪教训：“有的时候，代码能运行就不要尝试去改，哪怕是遇到屎山一样的代码”，可能还会对新人建议道：“人跟代码有一个能跑就行了。”

那么，你是否在工作中遇见过令人发指的“祖传代码”，最长拥有多少年历史？你是选择逐一改动还是放任不管？