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

判断

对正在考虑宣布旧系统「不可救」、另起炉灶重写的技术负责人，Willison 的取舍是先投自动化测试和定向重构，而不是开新项目——代价是短期内还得继续替旧账买单。

依据

Simon Willison 在 Lobste.rs 的回复里说，他几乎没见过「推倒重写」成功：宣布旧系统被技术债（technical debt，即赶进度时留下、日后要额外偿还的代码负担）淹没之后另起一个团队，旧系统却仍在跑核心业务，改动照旧；维护旧系统的人知道它很快会被替换，只肯做最小投入，技术债继续堆。他给出的对照数字是新系统里 80% 是闲置代码——重写团队起初节奏很快，但没人完全清楚被替换系统的行为与范围（若文档测试齐全，本就不必替换），拖到压力上来只能先上线少数功能，于是两套系统并存生产环境，还可能因「优先级变了」而彻底烂尾。他因此主张：先把旧系统的自动化测试补厚，再看定向重构能否把它改到需要的形状，并推荐 Will Larson 的《Migrations: the sole scalable fix to tech debt》。