行业动态Simon Willison
代码可以坏到什么程度，没有上限坏代码无上限，提醒我们警惕技术债累积，重构需及时。
对正在考虑宣布旧系统「不可救」、另起炉灶重写的技术负责人，Willison 的取舍是先投自动化测试和定向重构，而不是开新项目——代价是短期内还得继续替旧账买单。
展开全文收起
依据
Simon Willison 在 Lobste.rs 的回复里说，他几乎没见过「推倒重写」成功：宣布旧系统被技术债（technical debt，即赶进度时留下、日后要额外偿还的代码负担）淹没之后另起一个团队，旧系统却仍在跑核心业务，改动照旧；维护旧系统的人知道它很快会被替换，只肯做最小投入，技术债继续堆。他给出的对照数字是新系统里 80% 是闲置代码——重写团队起初节奏很快，但没人完全清楚被替换系统的行为与范围（若文档测试齐全，本就不必替换），拖到压力上来只能先上线少数功能，于是两套系统并存生产环境，还可能因「优先级变了」而彻底烂尾。他因此主张：先把旧系统的自动化测试补厚，再看定向重构能否把它改到需要的形状，并推荐 Will Larson 的《Migrations: the sole scalable fix to tech debt》。
- 宣布旧系统被技术债淹没开新项目
- 组建团队从零重写并行运行
- 旧系统继续承接业务变更压力下先上线
- 新系统只上线少数功能
没写清 材料只给作者的经验与直觉（原文自称 My hunch），没有定向重构与重写两条路径的成功率或案例数字，所以不能替它算出哪边的胜算更大。
下一步 把《Migrations: the sole scalable fix to tech debt》读完，并对现有系统做一次自动化测试覆盖盘点。