默认选择 refactor。只有当现有系统再也无法以可接受的成本演进以满足需求,且你能在重写期间持续交付价值时,重写才是合理的。大多数“我们需要重写”的直觉,其实是一个未被管理的 tech-debt 问题,而渐进式 refactor 能以小得多的风险解决它。
我如何推理
- 核心架构还可行吗? 如果数据模型、边界和运行时能伸展到新需求,就 refactor。如果基础假设错了(错误的存储范式、无法扩展、语言/平台已 end-of-life),重写才成为真正的候选。
- 变更频率是多少? 很少改动的代码不需要漂亮。把精力集中在团队每天工作的地方。
- 我们理解当前的行为吗? 重写会扔掉多年编码进去的边界情况知识。如果没有测试也没有 spec,重写会重新引入旧的 bug。
