接手一套十年老系统：重构、重写还是继续维护？一份可落地的判断框架

一套跑了十年的业务系统，通常有三个共同特征：业务离不开它，代码没人敢动，改一个字段能牵出五个模块。交接的时候能拿到的文档往往只有两页，其中一页还是安装说明。

这时候会议室里一定会出现三种声音：产品说“这系统太老了，推倒重做吧”；技术负责人说“重写风险太大，先重构”；老板说“能用就行，别折腾”。三种声音都有道理，因为它们各自只看到了问题的一面。

老系统改造真正难的地方，不是技术选型，而是先判断清楚这套系统到底该走哪条路。方向选错，后面投入的每一分钱都在放大错误。

先别写代码，给系统做一次五维体检

在讨论方案之前，建议先花两三天把下面五个维度量化出来。不需要多精确，能排出高低顺序就够用。

这五项里，变更频率和故障成本决定“要不要动”，可测性与依赖耦合决定“能不能动”。前者是需求侧的压力，后者是供给侧的条件。很多改造项目失败，是因为只看了压力、没看条件。

把体检结果放进下面这张对照表里，答案通常就浮出来了。

路径	适合的系统	主要代价	典型风险
继续维护	业务稳定、需求极少、故障可接受	每年少量维护人力	关键开发人员流失后无人接手
渐进式重构	业务在持续演进，系统要一直活着	周期长，需要长期投入	新旧逻辑并存，边界不清越改越乱
彻底重写	架构已到天花板、依赖少、业务可停或可并行	一次性投入大，双轨运行成本高	周期失控，上线即“第二套老系统”

这里有一个常被忽略的事实：“继续维护”不是不作为，而是一种合法决策。 一套每年只改两次、故障影响可控的内部系统，投入几百万重写，从商业上看并不划算。真正的问题不是系统老，而是它是否还在拖累业务。

重写听起来最痛快，也最容易在立项会上赢得掌声。但它失败的原因往往与技术无关，而是下面三点：

一、业务规则藏在代码的角落里。 十年间积累的规则，很多从未写进文档：某个客户的特殊折扣、某笔历史数据的手工修正、某个只在月底才走的分支。老系统的代码再乱，它也是一份可执行的业务说明书。重写时一旦漏掉一条，上线当天就会以事故的形式暴露出来。

二、第二系统效应。 重写的人往往带着“这次一定要做对”的心态，于是架构越设计越大，范围越铺越广，交付时间从六个月推到两年。而在这两年里，老系统还得继续改需求——两个系统同时维护，团队被撕成两半。

三、并行期没有终点。 理想中是“新系统上线，老系统下线”，现实常常是“新系统只承接了新业务，老数据还在老库里”，双轨运行变成常态，维护成本比改造前更高。

所以业界的共识是：除非架构已经彻底堵死，否则优先选择渐进式重构。 把一次大赌注，拆成很多次可以随时停手的小风险。

最常用也最稳妥的做法叫“绞杀者模式”——不去动老系统内部，而是在它外面长出新枝，一段一段把流量接过来。

划边界。 沿着业务能力把系统切成若干块（订单、库存、结算、报表），先选出“改动最频繁、耦合最浅”的一块作为突破口。别从最核心的支付链路开刀，那是给自己上难度。
建围栏。 在老系统前面加一层统一入口（网关或反向代理），让所有流量先经过它。这一层是后面所有动作的前提——没有流量入口，就做不了灰度切换。
摘模块。 新模块独立开发、独立部署，通过入口按比例或按用户灰度接管流量。老代码原封不动留着，随时可以切回去。
清尾款。 模块切换稳定运行一个月后，把老系统里对应的代码和数据表正式下线。这一步最容易被跳过，也是“重构做完却越背越重”的根本原因。

这套办法的妙处在于：每一步都可以停。 预算收紧时可以停在第二步，业务调整时可以只重构其中两块，不必等到全部完成才有收益。

坑一：没有回归测试网就动手。 重构的前提是“改完知道有没有改坏”。如果系统至今靠手工点击验证，第一件事应该是给核心链路补上自动化用例，而不是急着拆模块。测试网是安全绳，不是可选项。

坑二：重构和新功能混在一个迭代里。 “顺手把这个需求也做了”是重构项目最常见的死法。重构迭代应该只改结构、不改行为，行为变更单独排期。两者混在一起，出问题时根本分不清是结构改坏了还是需求写错了。

坑三：只改代码，不动数据。 数据库往往比代码更难动——表结构混乱、字段含义靠口口相传、还有别的系统在直连。数据层的改造需要单独设计迁移与双写方案，别指望“代码重构完数据自然就顺了”。

老系统改造的本质是一场资源分配决策，而不是一场技术炫技。它需要回答的问题很朴素：这套系统未来三年还要承载多少业务？团队有没有能力在维护旧系统的同时建新的？公司能承受多长的双轨运行期？

如果把这几个问题答清楚，用什么框架、拆成几个服务，反而都是次要的。

最后留一个问题给正在面对这套系统的你：如果预算只够做一件事，你会先去补测试，还是先去拆那个最痛的模块？ 答案没有标准，但它能立刻暴露出团队真正缺的是什么。