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

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

这不，最近又有一个“倒霉蛋”火上了 HN 热榜：

“我继承了我见过的最差的代码和技术团队，该怎么办？”

01

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

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

• 这些代码每年能产生超过 2000 万美元的收入。

• 运行在 PHP 上。

• 已经在生产环境直接开发了 12 年，没有源代码控制（都是像 index-new_2021-test-john_v2.php 这种）。

• 没有使用 composer 或任何依赖管理，都是 require_once。

• 没使用任何框架。

• 路由管理完全是在 NGInX 中重写的（NGInX 的配置大约是 10000 行）。

• 这些年只在不断往上堆代码，没删除任何代码（我推测这是因为代码是直接在生产环境开发的，删东西太危险了）。

• 数据库结构也是一片混乱，没有迁移等等。要添加一个列时，由于数据量大，他们一般会建一个新表，然后用 join。

• JS 和 CSS 也是如此。jQuery 的不同版本互相打架，具体取决于你在哪个页面，有时甚至同一个页面也会有。

• 当然没有 MVC 模式或其他模式什么的，没有模板库。这是 PHP 2003 的样式。

• 在很多地方，我看到像是 Controller 一样的文件，向它自己的 rest API 发出 curl 请求（通过域名而非 localhost）进行 oauth 授权等…然后只是为了获取菜单项或产品列表。

• 没有缓存（但有 memcached ，但只用于 Session…)。

• 团队只有 3 个很年轻的人，一个后端，一个前端，一个 iOS/android ，他们对代码变革非常抵触。

• 生产力很差，这可以理解——乱七八糟的东西实在是太多了，根本没办法做新东西。

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

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

因此，@whattodochange 发帖求助：

“我知道完全重写是必要的，但要如何平衡？”

图源：视觉中国

02

逐一改动 or 摆烂跑路？

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

“完全重写不是必需的，甚至可能是最糟糕的方法。可以一次做一件事，最终你会重写所有代码，但永远不会陷入‘完全重写’的陷阱中。

不过在重写一行代码之前，记得要做大量的测试。如果有端到端测试，这些测试运行在客户群当前使用的每个功能中，那么您就有一个基线来安全地进行更改。只要测试通过，就可以删除代码。

不要想着去推动变革，尝试拥抱这个每年赚 2000 万美元的可怕代码库，和团队讨论讨论如何在能力范围内改进即可。”

作为这个开发团队的经理，你的任务是要得到高管支持来逐渐解决这个烂摊子。你没必要告诉高管或团队具体要如何修复，只要有时间和空间上的支持就好。

有一种办法是每周五集合团队一起来测试，但可能会经常被紧急任务挤掉；另一种办法是让每个更新的发布速度稍慢一些，这样就有时间优化每次更新所涉及到的其他代码。例如，业务要求添加功能 X，那么你就给相关的现有功能 Y 添加一个测试，可以对团队说优化 Y 是为了让添加 X 更为方便。”

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

“你应该考虑辞职。虽然你知道这代码很烂，但它确实能带来每年 2000 万美元的收入，所以你的团队不想变革，业务人员也不会关心代码质量。他们会认为：反正 2003 年样式的 PHP 代码就可以实现这个收入，那不挺好，干嘛要浪费财力和精力去重写？

最后，你很难说服你的开发团队和业务部门同意重写这个决定，甚至还会招来仇视，而你自己也会讨厌这样的工作氛围。”

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

03

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

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

• 《GTA 5》联机版中循环 19.8 亿次的 if 语句，被许多人称作游戏开发史上最大的“屎山”代码，存在了 7 年 R 星（游戏开发商 RockStar）的程序员无人敢动。最终，还是一位黑客大哥看不下去给出了解决方案，R 星这才官宣要修复 bug，并给这位黑客奖励了 1 万美元。

• 一位亚马逊工程师也曾形容他们公司的代码为：“一座很大的屎山，一座你见过的最大的山，每次你想修正一个 bug，都得爬到屎山的正中央去。”

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

• “公司代码已经 40 年了，最早写代码的人不知道是否活着，要命的是文档没留下，项目代码堆在一起能有 90 多 G。”

• “我要升级的那批代码写于 2000 年前，最早的部分可能写于 1980 年代贝尔实验室。第一批维护升级做需求的人早就退休了，第二批也退休了，每一行代码动起来都胆战心惊。”

• “曾经在 Visa 工作过，感觉什么 10 年 20 年的代码简直 naive，你见过 1965 年的代码吗？第一次看到简直惊呆了，这半个世纪的代码现在还在用还跑的好好的？”

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

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

参考链接：

• https://news.ycombinator.com/item?id=32883596

• https://www.zhihu.com/question/272065178