代码能坏到什么程度，没有上限

我在Lobste.rs上对《代码可以烂到什么程度没有上限》一文的评论。[回复一条关于当技术债变得不堪重负时推倒重来的评论] 以我的经验来看，这种做法很少能奏效。你宣布旧系统已深陷技术债、无法挽回。你组建一个团队从零开始重写。工作启动了。与此同时，旧系统仍是一个不断变化的目标：它运行着核心业务，因此改动仍然必要。负责旧系统的开发者知道它很快会被新系统取代，所以他们没有任何动力去付出超出最小努力的成本来添加新功能。技术债继续累积。与此同时，新系统的开发团队雄心勃勃，可能也有点天真。他们起步时速度很快——毕竟是从零开始——但随着时间推移，问题逐渐显现：没有人完全理解他们正在替换的那个系统的行为和范围。毕竟，如果旧系统有完善的文档和测试，它就不需要被替换了……在数月（甚至数年）没有交付价值之后，压力变成了“赶紧上线”，于是新系统被推出，只处理旧系统功能的一个子集——或者常常是为了某个新功能，而这个功能在如今几乎无人维护的旧系统上太难实现了……于是现在你有两套系统在生产环境中运行——一套没人想碰的破旧旧系统，以及一套只处理少数生产功能、80%是未激活代码、意在最终取代旧系统的新系统。如果你运气够好，公司还没对新系统失去耐心，会允许这项工作继续下去。整个过程拖得越久，旧系统在生产环境中坚持运行的时间越长，“优先级已经改变”的风险就越高，新系统全面替换的工作可能被放弃，最终留下两套系统，而原本只有一套。我读过的关于负责任地完成这一过程的最佳文章是Will Larson的《迁移：解决技术债的唯一可扩展方法》。如果将来我遇到类似情况，我的强烈建议是先用尽可能多的自动化测试加固旧系统，然后看看有针对性的重构能否让它达到理想状态。我的直觉是，在很多情况下，这比从头替换的诱惑有更高的成功概率。标签：迁移、技术债