遗留系统改造：何时重构，何时重写，何时维持不动

评估框架

我们从三个维度打分：业务价值（该系统支撑的业务是否仍在增长）、技术债务（维护成本与故障率）、替换成本（业务规则复杂度与迁移数据量）。

• 高价值 + 高债务：优先重构，采用绞杀者模式逐步替换模块，避免大爆炸式切换
• 低价值 + 高债务：考虑下线或替换为标准产品，不必投入定制开发
• 高价值 + 低债务：维持现状，投入应转向周边能力建设
• 低价值 + 低债务：维持不动，直到业务价值或债务状况发生变化

关于重写

完全重写失败的常见原因，是把“看不懂老系统”误判为“老系统没有价值”。老系统里往往沉淀了大量未被文档记录的业务规则与边界条件，重写时容易遗漏，上线后才集中暴露。

如果确实必须重写，建议先做充分的业务规则提取——可以通过日志分析、数据库字段审计与老员工访谈交叉验证——再进入开发。