核心问题

为什么面对旧系统时，第一反应不能是“这代码太烂了”？

真实场景

新团队接手一个老后台，发现命名混乱、逻辑重复、接口很绕。有人说：“这系统没救了，重写吧。”

听起来痛快，但这往往是危险信号。

常见误区

坏判断是：

我看不懂，所以它一定不合理。

旧代码可能确实糟糕，但也可能承载了你还不知道的业务例外、历史事故和临时约束。

工程视角

旧系统的奇怪设计背后，常常有原因：

  • 当年时间很紧。
  • 某个大客户有特殊规则。
  • 曾经发生过事故，所以加了保护逻辑。
  • 下游系统无法修改，只能在这里兼容。
  • 数据曾经迁移过，留下历史字段。

看起来丑的东西，不一定没有功能。

PM 可以怎么做

PM 可以帮助团队先还原历史：

  • 这段逻辑什么时候加的？
  • 当时解决了什么问题？
  • 有没有对应需求、事故或客户？
  • 现在这个原因还存在吗？
  • 删除或改写会影响谁？

Atlas Action

当团队想重写某段旧逻辑时，先要求回答：

它为什么存在？
如果删掉，谁会受影响？
我们怎么验证影响范围？

小结

旧系统不值得迷信，也不该被轻视。

PM 的成熟，是在推动改进之前，先帮助团队理解历史。