烂代码没有下限

评论 我的留言，回应 《烂代码没有下限》 —— Lobste.rs

（针对那条建议：当技术债务压倒一切时，不如推倒重来。）

根据我的经验，这种方案能成功的概率极低。

你宣称老系统已无可救药地深陷技术债务，于是组建团队从零重写，然后开工。

与此同时，老系统仍在变动：它跑着核心业务，变更仍然不可避免。开发人员知道它很快就会被新系统取代，因此毫无动力去多做哪怕一点点努力，只求最低限度地满足新需求。技术债务继续累积。

而另一头，负责新系统的团队雄心勃勃，也许还有点天真。起初进展神速——毕竟是全新项目——但随着时间推移，大家逐渐意识到，没人真正理解要替换掉的那套系统的行为和边界。毕竟，如果老系统文档齐全、测试完备，也就不需要被替换了……

数月（甚至数年）过去，迟迟没有交付价值，压力逼迫着你们"赶紧上线"。于是新系统匆匆推出，只接管了老系统功能的一个子集——或者干脆只为实现某个新功能，而这个功能在老系统日益荒废的维护状态下早已难以构建。

……结果你现在有了两套生产系统：一套没人敢碰的破烂老系统，加上一套仅处理少数生产功能、却充斥着 80% 为替代老系统而写、最终却闲置的代码的新系统。

如果你运气好，公司还没对新系统失去耐心，允许工作继续推进。整个过程拖得越久，老系统在生产线扛住不崩的时间越长，"优先级变了"的可能性就越高，最终新系统的全面替代工作会被放弃，留下两副残局，而你从前只有一套系统。

关于如何负责任地完成这类迁移，我读过最好的文章是 Will Larson 的 《Migrations: the sole scalable fix to tech debt》。

如果以后再遇到这种情况，我的强烈建议是：先给旧系统补上尽可能多的自动化测试，然后看看有针对性的重构能否把它改造成理想的形态。我的直觉是，在许多情况下，这条路比“推倒重来”的诱惑更有可能成功。