概要

老系统不好维护时，团队很容易形成两个极端观点：

• “这个系统已经没救了，必须全部重写”；
• “现在还能跑，千万不要动”。

两种判断都可能有道理，也都可能把项目带入困境。

我参与过大型中台的服务聚合、接口治理、异构平台迁移和领域模型建设。实践中，决定是否重构的关键并不是代码“看起来有多旧”，而是业务价值、风险边界、经济账和演进路径能否同时成立。

在启动重构前，我通常先看以下四项。

一、业务价值：系统问题是否真的阻碍了业务

技术团队常见的不满包括代码重复、框架老旧、分层不标准、测试不足。这些是技术债，但不一定足以支持一场大规模重构。