重写系统很少是技术债的解药
当一个系统被技术债拖到难以维护时，团队很容易产生一个直觉：干脆推倒重写。
但在实际经验中，这种做法很少真正成功。
推倒重写的常见剧本
通常，事情会这样展开：
团队宣布旧系统已经被技术债淹没，无法挽救。于是公司组建一个新团队，从零开始重写。项目启动，一切看起来都很有希望。
与此同时，旧系统并不会停下来。
它仍然承载核心业务，所以仍然需要不断变更。维护旧系统的开发者知道它很快会被新系统取代，因此也缺乏动力去做长期改进。他们更可能用最小代价补上新需求。结果是，旧系统的技术债继续增加。
另一边，负责新系统的团队往往雄心勃勃，也可能有些天真。刚开始时进展很快，毕竟是绿地项目，没有历史包袱。但随着时间推移，团队会逐渐发现：没人真正完整理解旧系统的行为、边界和所有细节。
如果旧系统有完善文档和测试，它也许本来就不需要被整体替换。
新系统上线后，问题不一定减少
几个月，甚至几年过去后，新系统还没有交付足够业务价值，压力开始出现：必须上线。
于是新系统通常会先承接旧系统的一部分功能，或者承接某个在旧系统上已经很难实现的新功能。
结果是，组织现在有了两个生产系统：
- 一个没人愿意碰、但仍在运转的旧系统；
- 一个只处理少量生产功能的新系统；
- 新系统里还可能存在大量“未来用于替换旧系统”的闲置代码。
如果运气足够好，公司还愿意继续投入，让迁移工作推进下去。
但时间拖得越久，旧系统继续稳定运行的时间越长，风险就越高：业务优先级改变，彻底替换计划被搁置。最终，原本只有一个难维护系统，现在变成了两个需要维护的系统。
更稳妥的方向：测试与定向重构
关于如何负责任地完成这类迁移，Will Larson 的《Migrations: the sole scalable fix to tech debt》是一篇值得参考的文章。
如果未来再次遇到类似情况，更稳妥的建议可能是：
- 先尽可能为旧系统补充自动化测试；
- 用测试保护现有行为；
- 再通过有针对性的重构，把系统逐步调整到理想形态。
相比从零重写，这种方式在许多场景下成功概率可能更高。
推倒重写的诱惑很强，尤其是在旧代码已经让团队痛苦不堪的时候。但现实中，绿地替换往往不是捷径，而是另一种更大规模的迁移项目。如果没有清晰边界、测试保障和持续交付价值的路径，它很容易把一个技术债问题变成两个系统的长期负担。