选择重写而非重构的教训

前言

当模块边界本身就是错的，渐进式重构就不再是稳妥选项。文章回顾了一场持续两个季度的迁移：哪些东西被保留了下来、哪些建议被我们忽略，以及差点出事的两个环节。

小事的复利

回顾 Technical Discussion 的工作，真正的收获都不怎么华丽：一次命名修正、一个被删掉的配置、一份再也没改过的检查清单。

它们为什么留了下来

• 它们由一个人负责，而不是一个委员会。
• 它们上线时，附带了「何时会失效」的观察手段。
• 它们去掉了一个决策，而不是多写了一份文档。

直接拿走

挑一个这个月你已经抱怨过三次的痛点。那就是你的下一个项目——它已经证明过自己的生命力。

写在最后

大重写的故事更好听；小步复利的系统更好用。