代码重构实战：从屎山代码到可维护系统的进阶指南

1. 当代码变成"能跑但很烂"时

上周review同事的PR时，看到一段让我血压飙升的代码：一个300行的函数，嵌套了8层if-else，变量名全是a1、a2，还混着5种不同风格的错误处理。最绝的是注释写着"这里有个隐藏bug但线上跑两年没出过问题"——这简直就是教科书级的"屎山"代码(s**t mountain)。

这种"能跑但很烂"的代码每个程序员都遇到过：可能是赶工期埋下的坑，可能是多人接力维护的产物，也可能是早期设计缺陷的累积。它们就像程序里的定时炸弹，每次修改都战战兢兢。最近我用三周时间重构了一个5万行的历史项目，过程中总结出这套可复用的重构方法论。

2. 重构前的准备工作

2.1 建立安全网

动手前必须准备好三个安全措施：

1. 测试覆盖率：至少要有80%的单元测试覆盖率（用JaCoCo或Istanbul测量）。我通常会先给旧代码补测试，采用"测试三角"策略：

   java复制// 示例：给烂代码补测试的技巧
   public void testLegacyMethod() {
       // 1. 先用最小输入验证基础路径
       assertEquals(2, legacyMethod(1, 1));
       
       // 2. 用生产日志中的真实参数测试
       assertEquals(114, legacyMethod(realCaseParam1, realCaseParam2));
       
       // 3. 边界值测试
       assertThrows(IllegalArgumentException.class, 
           () -> legacyMethod(-1, Integer.MAX_VALUE));
   }
   

2. 性能基准：用JMeter或Locust记录关键接口的QPS和延迟。我曾经重构过一个"优化"后性能下降70%的案例——因为删掉了看似多余的缓存。

3. 行为快照：对复杂逻辑用Approval Tests保存输入输出快照。比如用下面的方式记录旧代码行为：

   bash复制# 生成行为快照
   ./legacy_app < test_input.json >