为什么大规模重写通常失败
Simon Willison··作者 Simon Willison
关键信息
Willison 建议先用尽可能多的自动化测试加固旧系统，再通过有针对性的重构逐步调整，而不是押注一次全新的替代开发。他还提到 Will Larson 的《Migrations: the sole scalable fix to tech debt》是他读过的、关于如何负责任地完成这类迁移的最佳文章。
资讯摘要
Simon Willison 这篇文章是在回应一种常见观点：当技术债已经严重到难以承受时，最好的办法就是推倒重来。他说，按照自己的经验，这种做法真正成功的情况非常少。原因在于，旧系统不会因为重写项目启动就停止运转，它仍然承载着核心业务，所以在新系统开发期间，旧系统还必须持续变化。这样一来，维护旧系统的人往往只会做最低限度的改动，因为他们知道它可能很快就会被替代。与此同时，新团队通常会在一个绿色田野代码库上高速推进，但随着时间推移，他们会发现自己并没有完全理解被替代系统的行为和范围。
几个月甚至几年过去，重写项目仍然没有带来实际价值，团队就会面临尽快上线的压力。Willison 说，最终常见的结果是生产环境里同时存在两个系统：一个是没人愿意再碰的遗留系统，另一个只是接管了旧系统一部分职责的新系统。若公司失去耐心，或者优先级发生变化，重写工作还有可能被直接放弃，最后组织的处境甚至比原来更糟。作为替代方案，他建议先为旧系统补上尽可能多的自动化测试，再通过有针对性的重构逐步把系统调整到目标形态。
资讯正文
<p><a href="https://lobste.rs/s/rfn2mn/there_s_no_limit_how_bad_code_can_get#c_8kdtaw">我的评论</a>，回应 <a href="https://lobste.rs/s/rfn2mn/there_s_no_limit_how_bad_code_can_get">There's No Limit to How Bad Code Can Get</a> —— Lobste.rs。</p><p><em>[回复一条关于在技术债务变得难以承受时把系统烧掉、从头开始重写的评论]</em></p>
<p>根据我的经验，这种做法 <em>极少</em> 能奏效。</p>
<p>你宣布旧系统已经被技术债务淹没，无法挽回。你组建一个团队从头重写它。工作开始推进。</p>
<p>与此同时，旧系统仍然是一个不断变化的目标：它在支撑核心业务，所以仍然必须做修改。负责它的开发者知道它很快就会被新系统取代，因此他们没有动力去付出超出最低限度的努力来添加新功能。技术债务继续累积。</p>
<p>与此同时，负责新系统的团队雄心勃勃，而且大概还有点天真。他们一开始进展神速——毕竟这是全新的绿地项目——但随着时间推移，大家逐渐发现，没有人真正完全理解他们正在替换的那个系统的行为和范围。毕竟，如果它文档完善、测试充分，它就<em>不需要</em>被替换了……</p>
<p>在几个月（甚至几年）都没有交付价值之后，压力会转向“赶紧上线”，于是新系统被推出，用来处理旧系统所处理内容中的一部分——或者常常只是为了实现某个新功能，而这个功能已经很难在如今几乎无人维护的旧系统上构建出来。</p>
<p>……于是现在你有了生产环境中的两个系统——一个破破烂烂、没人想碰的旧系统，以及一个只处理少数几个生产功能的新系统；后者有 80% 是处于闲置状态、原本打算最终取代旧系统的代码。</p>
<p>如果你<em>真的幸运</em>，公司不会对新系统失去耐心，并且会允许这项工作继续下去。整个过程拖得越久，旧系统在生产环境里继续运行并顽强地维持可用的时间越长，“优先级已经变了”的风险就越高，新系统的彻底替换工作会被放弃，最后你得到的是两个系统，而不是原来的一个。</p>
<p>我读过的、关于如何负责任地完成这一过程的最好文章，是 Will Larson 写的 <a href="https://lethain.com/migrations/">Migrations: the sole scalable fix to tech debt</a>。</p>
<p>如果我将来再遇到类似情况，我的强烈建议会是：先尽可能用自动化测试把旧系统加固起来，然后看看有针对性的重构能否把它调整到所需的形态。我的感觉是，在很多情况下，这样成功的概率会比绿地重建的海妖之歌高得多。</p>
<p>Tags: <a href="https://simonwillison.net/tags/migrations">migrations</a>, <a href="https://simonwillison.net/tags/technical-debt">technical-debt</a></p>
来源与参考
收录于 2026-09-07