1. 重构无单元测试代码的困境与破局

面对没有单元测试的遗留代码库时，重构就像在雷区里跳探戈——每次修改都伴随着未知风险。我经历过一个Java EE老系统，20万行代码零测试覆盖率，最初两周的"小改动"引发了五次线上事故。这种痛苦促使我系统性地研究了无测试环境下的安全重构方法论。

2. 无测试环境下的重构策略

2.1 建立安全网：测试优先原则

在修改任何代码前，先用"接缝测试"(seam test)包裹目标代码块。比如一个计算订单折扣的古老方法：

// 原始代码 public BigDecimal calculateDiscount(Order order) { // 复杂的业务逻辑嵌套着数据库调用 if (order.getItems().size() > 5) { BigDecimal total = orderService.getHistoricalTotal(order.getCustomerId()); return total.compareTo(BIG_THRESHOLD) > 0 ? new BigDecimal("0.1") : BigDecimal.ZERO; } // 更多嵌套条件... }

应该先创建这样的测试夹具：

@Test void calculateDiscount_goldCustomerWith7Items_returns10Percent() { // 给定 Order testOrder = TestOrderBuilder.create() .withCustomerType("GOLD") .withItems(7) .build(); // 当 BigDecimal result = legacyCalculator.calculateDiscount(testOrder); // 那么 assertEquals(new BigDecimal("0.1"), result); }

关键技巧：使用Mockito等工具隔离数据库依赖，通过构建器模式创建测试数据。我习惯将这类测试标记为@IntegrationTest单独运行。

2.2 增量式重构技术

2.2.1 提取方法对象

将复杂方法转为带状态的类，比如把上述折扣计算重构为：

public class DiscountCalculator { private final Order order; public DiscountCalculator(Order order) { this.order = order; } public BigDecimal execute() { return isBulkOrder() ? getVolumeDiscount() : BigDecimal.ZERO; } private boolean isBulkOrder() { ... } private BigDecimal getVolumeDiscount() { ... } }

这样做的好处是：

1. 可以单独测试各个子条件
2. 状态转移变得显式
3. 符合单一职责原则

2.2.2 引入防腐层

对于重度耦合的代码，我会创建适配器接口：

public interface OrderDiscountService { BigDecimal calculate(Order order); } public class LegacyDiscountAdapter implements OrderDiscountService { private final LegacyCalculator delegate; @Override public BigDecimal calculate(Order order) { // 在这里添加日志/监控 return delegate.calculateDiscount(order); } }

3. 工具链支持方案

3.1 静态分析先行

组合使用以下工具：

1. SonarQube：检测代码异味
2. ArchUnit：验证架构约束
3. JDepend：分析包依赖

我的标准工作流：

mvn clean compile mvn sonar:sonar -Dsonar.login=your_token mvn test-compile org.archunit:archunit-maven-plugin:analyze

3.2 可视化辅助

使用IntelliJ的"Analyze → Data Flow"功能追踪变量传播路径，配合"Diagrams → Show Dependencies"生成依赖图。对于特别复杂的逻辑，我会用PlantUML画出控制流：

@startuml start :输入订单; if (商品数量 > 5?) then (是) :查询历史订单; if (历史金额 > 10000?) then (是) :返回10%折扣; else (否) :返回0; endif else (否) :返回0; endif stop @enduml

4. 风险控制实践

4.1 变更安全网

实施三层防护：

1. Git预提交钩子运行静态检查
2. CI流水线执行冒烟测试
3. 生产环境部署后立即运行健康检查

我的团队使用这样的checklist：

4.2 监控增强

在关键路径注入监控点：

public class InstrumentedCalculator { private final MeterRegistry registry; public BigDecimal calculate(Order order) { Timer.Sample sample = Timer.start(registry); try { return delegate.calculate(order); } finally { sample.stop(registry.timer("discount.calc")); } } }

配合Grafana设置这样的告警规则：

sum(rate(discount_calc_seconds_count{status="500"}[5m])) by (service) / sum(rate(discount_calc_seconds_count[5m])) by (service) > 0.05

5. 团队协作模式

5.1 结对编程规范

采用"驾驶员-领航员"模式：

1. 驾驶员专注当前代码修改
2. 领航员负责：
   • 记录修改影响点
   • 维护TODO列表
   • 监控静态分析报告

我们使用简单的Markdown模板记录会话：

## 重构会话 2023-07-20 **目标**：解耦订单折扣计算 **参与者**：张三（驾驶）、李四（领航） ### 修改记录 - [x] 提取VolumeDiscountStrategy - [ ] 移除对OrderService的直接依赖 ### 风险点 1. 会员等级计算涉及3个调用点 2. 历史数据迁移脚本需要同步更新

5.2 代码评审要点

重点关注：

1. 接口契约是否保持不变
2. 新测试是否覆盖边界条件
3. 监控指标是否完备

典型评审注释示例：

- // 直接调用外部服务 + // 建议通过防腐层访问，方便后续mock BigDecimal total = orderService.getHistoricalTotal(customerId);

6. 实战案例：电商促销系统改造

最近重构的促销引擎包含这些关键步骤：

1. 建立基准
   用JMeter录制生产流量，保存为基准测试集

2. 提取领域模型

   // 重构前 public void applyPromotion(long userId, List<Item> items) { // 200行混合逻辑 } // 重构后 public PromotionResult apply(PromotionContext context) { return promotionStrategies.stream() .filter(s -> s.canApply(context)) .findFirst() .map(s -> s.apply(context)) .orElse(PromotionResult.empty()); }

3. 渐进式验证
   使用双跑模式验证：

   // 在测试环境同时运行新旧版本 @Test void promotion_compatibilityTest() { PromotionResult oldResult = oldEngine.apply(user, items); PromotionResult newResult = newEngine.apply(context); assertEquals(oldResult.getDiscount(), newResult.getDiscount()); assertEquals(oldResult.getGifts(), newResult.getGifts()); }

这个项目最终达成：

• 核心复杂度降低60%
• 测试覆盖率从0%提升到75%
• 促销配置错误导致的工单减少90%

7. 经验总结

1. 认知负荷管理
   每次重构范围控制在2小时能理解的代码量内，超过则分解任务

2. 防御性提交
   每个git commit包含：

   • 独立的测试用例
   • 对应的实现修改
   • 影响文档更新

3. 度量驱动
   每周跟踪：

   • 圈复杂度变化趋势
   • 构建失败次数
   • 生产缺陷关联度

最有效的策略是从系统边缘开始重构，逐步向核心推进。就像修复古建筑，先加固外围结构，再处理承重墙。记住：没有银弹，只有持续的小步前进。