核心问题

面对烂代码，什么时候该重构，什么时候该暂时忍受？

真实场景

一个模块很难读，但这次需求只改一个小字段。工程师想顺手重构，PM 担心延期。

双方都没错。问题是：这次重构是否值得？

常见误区

坏判断有两种：

只要代码烂，就必须立刻重构。

以及：

只要能跑，就永远不要动。

前者忽视交付成本，后者放任技术债滚雪球。

工程视角

重构值得发生在这些场景：

  • 这段代码正在频繁变化。
  • 当前结构已经明显拖慢交付。
  • Bug 多次出现在同一区域。
  • 新需求会让旧结构更糟。
  • 有测试或灰度手段保护修改。

如果只是“看着不爽”，不一定值得现在动。

PM 可以怎么做

PM 可以把重构变成投资判断：

  • 不重构会增加多少未来成本？
  • 重构会影响本次交付多少？
  • 有没有小步重构方案？
  • 能不能和当前需求顺路做？
  • 如何验证没有破坏旧行为？

Atlas Action

使用一句判断：

如果这段代码未来还会频繁变化，重构是投资；如果它几乎不再变化，忍受可能更经济。

小结

重构不是洁癖，也不是奢侈品。

它是一种工程投资，PM 要帮助团队判断投资时机。