先看业务代价，而不是代码年龄

老代码并不天然需要重构。真正值得警惕的是：一个正常的业务变化，是否总会触发无法预估的连锁反应；团队是否开始回避修改某些模块；发布是否越来越依赖少数人。

三个可以量化的信号

  1. 同类需求的交付周期持续变长。
  2. 故障恢复越来越依赖人工经验。
  3. 新成员需要很久才能安全修改核心模块。

重构应该从最影响业务的边界开始，并且在每一个阶段都能交付可见价值。一次性推倒重来，往往只是把旧风险换成新风险。