代码能有多烂，是没有上限的

我的评论 关于 代码可以有极限 — Lobste.rs。

［针对一条关于当技术债务积重难返时干脆推倒重来的评论］

依我的经验，这种做法能奏效的情况极其罕见。

你宣布旧系统已深陷技术债务、无力回天；随即组建一支团队从头重写；开发工作正式启动。

与此同时，旧系统依然是个不断变化的“靶子”：它承载着核心业务，因此仍需持续迭代。而负责维护它的开发人员清楚，这套系统很快就会被新系统取代，于是他们缺乏动力，只做最低限度的改动以满足新增需求。结果，技术债务越积越重。

另一边，负责新系统的团队往往雄心勃勃，但也未免有些天真。起初进度飞快——毕竟是全新起步——可随着时间推移，大家逐渐意识到：没人真正理解被替换系统的运行逻辑与业务边界。毕竟，如果它文档完善、测试充分，也就没必要被替换了……

几个月（甚至几年）过去，价值迟迟未能兑现，压力之下只好“硬上”，于是新系统先上线，仅承接旧系统部分功能——或者干脆用来实现一些用那套几乎无人维护的旧系统难以完成的新特性。

……于是，生产环境里一下子出现了两套系统：一套没人愿意碰的“破烂货”，以及一套只支撑少数生产功能、80%都是闲置代码、本应最终取代旧系统的“新家伙”。

如果你真够幸运，公司还没对新系统失去耐心，还会允许这项工作继续推进。但整个过程拖得越久，旧系统又偏偏一直稳定运行、不肯“退休”，“优先级变了”、彻底放弃新系统替代工作的风险就越高，最后落得手里两套系统，却还不如当初的一套。

关于如何负责任地走完这一流程，我读过的最佳文章是 Will Larson 的 迁移：唯一可扩展的技术债务解决方案。

如果未来再遇到类似局面，我的强烈建议是：尽可能为旧系统补上自动化测试，然后看看通过有针对性的重构能否让它达到理想状态。我的直觉是，在很多情况下，这样做成功的概率远高于盲目追求全新起步的“绿野仙踪”式诱惑。

标签：迁徙、技术债务