祖传代码重构实战：从面条代码到模块化设计

1. 项目概述：当祖传代码遇上现代工程

接手祖传代码就像考古学家发掘古代遗址——既有发现历史宝藏的兴奋，又得面对年久失修的结构风险。这类代码通常具有三个典型特征：函数长度超过千行、全局变量四处蔓延、业务逻辑与UI渲染深度耦合。我曾维护过一个保险理赔系统，核心业务类竟有27个static修饰的公共变量，任何修改都可能引发连锁崩溃。

这种被称为"面条代码"（Spaghetti Code）的代码库，往往伴随着这些症状：修改一个bug会引发三个新问题、新人需要半年才能勉强上手、每次发布都像在拆定时炸弹。而OOP重构的价值在于，通过建立清晰的领域边界和职责划分，将系统从"牵一发而动全身"的脆弱状态，转变为模块间松耦合、功能可插拔的乐高式架构。

2. 重构前的准备工作

2.1 代码现状分析三板斧

在动手重构前，需要像医生问诊一样进行全面检查：

1. 依赖关系图谱：使用JDepend或ArchUnit生成模块依赖图。曾有个电商系统，订单模块竟反向依赖了支付网关的实现类，这是典型的架构异味。

2. 代码度量指标：

   • 方法长度（超过50行需警惕）
   • 圈复杂度（大于10应考虑拆分）
   • 重复代码率（同一项目中出现5次以上的相似代码块）

3. 运行时分析：通过APM工具定位热点方法。某物流系统重构时，我们发现一个计算运费的函数占用了30%的CPU时间，这正是性能优化的重点目标。

重要提示：必须建立完整的自动化测试套件（至少70%覆盖率）再开始重构，这是安全绳。我曾见过没有测试保护的重构导致线上事故的惨痛案例。

2.2 领域模型提炼术

从混乱代码中提炼领域模型是重构的核心：

1. 名词收集法：扫描代码中的业务名词，如"保单"、"理赔单"，这些往往是潜在的领域对象。

2. 行为归并：将分散在各处的相似操作集中。例如所有计算保费的逻辑，不论当前在Controller还是Util类中，都应归于PremiumCalculator。

3. 四色建模实践：

   • 粉红色：核心领域实体（如Policy）
   • 黄色：业务过程（如Underwriting）
   • 蓝色：描述信息（如InsuredPerson）
   • 绿色：辅助规则（如DiscountRule）