存量系统重构：先画图，再动代码

重构最贵的成本不是写代码，而是"看不见"。不知道哪些地方被谁调用、不知道哪张表其实还在用、不知道删掉一个字段会影响几个报表——在这些问题搞清楚之前动代码，等于蒙着眼睛拆墙。

一、看不见，是重构最大的一笔隐形成本

存量系统的典型特征是：文档缺失、原作者离职、逻辑靠口口相传。此时最容易出现的两种错误做法，一是"照着现在的功能重写一遍"，二是"边看边改、走到哪算哪"。前者会把历史缺陷一起搬过去，后者会在中途失控。

正确顺序只有一句话：先把现状画出来，再决定动哪里。

二、三张图，把现状画出来

1. 业务流程图：谁在什么条件下做什么，异常分支怎么走。这一层要和业务人员一起对，不能只听开发说
2. 数据表关系图：哪些表是核心业务表，哪些是历史遗留表，哪些字段其实已经没人写只有人读
3. 调用关系图：模块之间谁依赖谁，有没有环形依赖，外部系统从哪里进来

三、给每一块现状分类

"别动"是一类正经结论，不是偷懒。在缺乏测试与文档的前提下，把一个低频但关键的老模块留着，比冒险重写更理性。把它圈出来、补上日志，等条件成熟再处理。

四、让业务不中断的三种做法

• 绞杀者模式：新需求走新系统，老功能按优先级逐步迁移，直到老系统自然退役
• 双跑比对：新旧逻辑同时运行，比对输出结果，一致率达到约定标准后再切换
• 影子流量：把真实流量复制一份给新系统，只看结果、不对外服务，用来暴露边界情况

三种做法可以叠加使用。核心原则是：任何一次切换都要有"退回去"的路径，而不是靠上线后现场救火。

五、怎么证明"改完更好了"

重构前先定指标，改完才有话说。建议至少记录四项：接口平均响应时间、发布频率（多久能安全上线一次）、故障平均恢复时间、上线后缺陷数量。没有基线的重构，最后只能停留在"感觉好了一些"。

把基线、改动、结果放在一张表里，重构就不再是一个说不清的技术动作，而是一件可以向业务解释清楚的事。