代码糟糕起来没有下限

# 评论：代码能烂到什么程度，没有下限 来源：https://simonwillison.net/2026/Sep/6/theres-no-limit-to-how-bad-code-can-get/ 2026年9月6日 *\[回复一条关于"当技术债务不堪重负时，应该推倒重来、从零开始"的评论\]* 以我的经验，这种做法*极少*能成功。 你宣布旧系统已经不可救药地深陷技术债务。你拉起一支团队从头重写。工作开始了。 与此同时，旧系统仍然是个**移动靶子**：它承载着核心业务，所以仍然需要改动。维护它的开发者知道这套系统很快会被新系统取代，因此他们在添加新功能时，只愿意付出最低限度的努力，不愿多走一步。技术债务持续累积。 与此同时，新系统的团队雄心勃勃，可能还有点天真。他们一开始进展神速——毕竟是 greenfield 项目——但随着时间推移，越来越明显的是，没人完全理解他们要替代的那个系统的行为和范围。毕竟，如果旧系统文档完善、测试充分，它也就*不需要*被替换了…… 在数月（甚至数年）没有交付价值后，"上线"的压力陡增，于是新系统被推出，只处理旧系统所承担功能的一个子集——或者常常只是为了实现某个在现已基本无人维护的旧系统上太难构建的新功能。 ……于是你现在有了两套生产系统：一套是没人想碰的摇摇欲坠的旧系统，另一套新系统只处理了少数生产功能，其中 80% 都是不活跃代码，本来打算最终取代旧系统。 如果你*真的走运*，公司还没有对新系统失去耐心，会允许这项工作继续。这一切拖得越久，旧系统在生产环境中待得越久、还顽固地继续运转，"优先级已经变了"的风险就越高，新系统全面替换的工作可能被放弃，最终你原本只有一套系统的地方，变成了两套。 我读过的关于如何负责任地完成这一过程的最佳文章，是 Will Larson 的 *Migrations: the sole scalable fix to tech debt*（https://lethain.com/migrations/）。 如果我将来遇到这种情况，我会强烈建议先用尽可能多的自动化测试加固旧系统，然后看看有针对性的重构能否把它改造成理想的形状。我的猜测是，在很多情况下，这种做法比 greenfield 重写那致命的诱惑要有高得多的成功概率。