代码重构入门与进阶：提升软件质量的实战指南

如果你要对已有代码中错误的命名方式进行修改，eclipse 提供了很好地支持：选择要修改的类、函数或变量，选择 Refactor——》Rename 可以同时修改该变量在声明和使用处的名称。

5. 常量命名

常量的命名除了要遵守上一小节提到的通用方法外，还有一类魔法数字（magical numbers）的情况，如使用 0,1 来代表男女。更恰当的做法是定义常量名来代替魔法数字，如在 Java 中：

public static final int FEMALE = 0;
public static final int MALE = 1;

这样在后续维护中，如果业务逻辑变更，只需修改常量定义处，而无需遍历整个代码库查找硬编码的数字。

6. 负值条件的重构

在条件或循环语句中，使用负值条件，会让代码难以理解、容易出错，比如判断是否为男性，条件写成了'!isNotFemale(gender)'。

重构方法是将条件改成正值，并调换 if/else 语句代码块的顺序。例如将 if (!isValid) 改为 if (isValid) 并将内部逻辑互换，这样可以减少双重否定带来的认知负担。

7. {} 作为单独的一行

正确的{}格式已经在 1 部分中提到，这里再强调下，如果你没有将括号作为单独的一行，如下所示：

catch (IOException e) { e.printStackTrace(); }

你得到的好处只是减少了一行代码，但是当你设置断点调试时，断点将不能精确定位到你想调试的部分。保持规范的换行有助于版本控制工具（如 Git）更清晰地展示差异。

8. 变量定义和使用距离太远

变量的定义和使用不要离得太远，一般不要超过 20 行，函数也类似。如果你意识到这个问题，但并不能缩短定义和使用的距离，那代表这是个大函数（big function），你需要对函数做拆分。

最佳实践提示： 每次只做微小修改，并保证测试能正确运行（小步快跑）。这是重构的核心原则，确保每一步改动都是安全的。

重构进阶

现在我们对重构已经有了基本的了解，并建立了初步的信心。让我们下面关注一些稍微复杂的重构内容。

1. 重复代码

当你发现相同的代码块在三个地方都出现时，你就需要考虑重构代码了。对于同一个类中重复的代码块，可使用提取方法（extract method：将重复代码提取出单独的函数）来完成；对于一组相关类如父类、子类 A、子类 B 中的重复函数，通过上移方法（pull method：将子类中的方法移入父类中）和模板方法（template method：父类方法定义模板，子类编写不同实现）来完成。

Eclipse 提供了相关功能，可以自动识别重复代码块并进行提取。这不仅能减少代码量，还能降低维护成本，一处修改多处生效。

2. 函数参数

• 开关参数的滥用（boolean parameters）： 函数的形参中有一个是 boolean 类型，函数体根据该参数为 true 或者 false 执行不同的代码块。这种方式会导致重构的另一个坏味道——大函数（big function）的形成，从而增加代码的复杂性。重构方法是：去掉这个开关参数，将函数拆分成两个函数。
• 在函数内修改了参数： 参数用于外界向函数体传递信息，好的做法是参数对于函数是只读的。如果在函数内修改参数，会造成函数功能难以理解，如果函数内多次修改参数，这个函数会变成一座迷宫。重构方法是：将参数赋值给局部变量，对局部变量修改。

原始代码示例：

int fun(int val) { 
    val = 32; 
    return val; 
}

修改后：

int fun(int val) { 
    int temp = val; 
    temp = 32; 
    return temp; 
}

• 参数太多： 函数的参数最多有三个是合理的，超过三个就需要提高警惕了。重构方法是：根据逻辑拆分函数；引入参数对象（parameter object：构造参数类，将原来传递的参数作为类的属性，调用方传入该类的一个对象）。

3. 变量多余

当定义的变量没太多含义，而且没有赋值操作，如下代码：

double basePrice = anOrder.basePrice(); 
return (basePrice > 1000);

其中的 basePrice 完全是多余的变量，完全可以用函数本身来替代它，如下代码：

return (anOrder.basePrice() > 1000);

这种简化减少了内存占用，也提高了代码的简洁度。

4. 缺少变量

某个临时变量被赋值超过一次，它既不是循环变量，也不被用于收集计算结果。如果它们被赋值超过一次，就意味着它们在函数中承担了一个以上的职责。如果临时变量承担多个责任，它就应该被替换为多个临时变量，每个变量只承担一个责任。

重构方法：针对每次赋值，创造一个独立、对应的临时变量。这有助于明确变量的生命周期和用途。

5. 复杂条件

我们都见过由 && || 构成的复杂的多行条件。复杂条件可读性很差，调试和修改也很麻烦。

一个简单的重构方式是：将这块代码抽取出来，变成一个单独的判断函数。例如：

原始代码：

double fetchSalary(double money, int day) { 
    if(money>10000 && day>30 ) { 
        return money * day / 365 * 0.2; 
    } else { 
        return money * 30.0 / 365 * 0.1; 
    } 
}

其中的条件 money>10000 && day>30 可重构为：

boolean isHigherSalary(double money, int day) { 
    return (money>10000 && day>30 ); 
}

这样主逻辑变得更加清晰，条件判断的逻辑被封装，便于单元测试。

老旧代码的重构

在进行代码重构时，需要考虑测试代码是否能覆盖重构的功能，如果没有，需要增加测试用例覆盖所做的修改，否则重构可能会破坏已有的功能。在前面的章节，作者假设已有足够的测试用例，并且重构完成后测试可以正确运行。

但是如何重构测试用例没有完全覆盖的代码呢？如老旧代码？作者的建议是只做必要的重构，如当需要修正 bug 或者增加新的功能，这种情况下，先为遗留代码编写测试用例，在理解的基础上重构代码，为代码修改做好准备，然后进行代码修改。

从这点上来说，你可以进行任何类型代码的重构：一次只做一步重构，从小的容易的重构做起，并频繁测试。引入测试驱动开发（TDD）思想，先写测试再重构，是保障安全的重要手段。

利用工具

重构代码需要花费时间，当项目工期很紧时，很难下定决心去做重构。为了让重构变得更容易，市面上提供了大量相关工具，如 pylint（Python 代码分析工具）、Checkstyle（代码规范工具）、Sonarqube（代码质量管理的开源工具）。

此外，你要保证你的测试用例跑的足够快，否则你会没有耐心等待测试运行结果，或者直接就不运行了。

理想情况下，程序在构建后部署到测试环境前，可以借助 CI/CD（持续集成/持续部署）工具实现代码质量检查、代码样式检查、潜在 bug 监测等模块的自动化运行。例如配置 Jenkins 或 GitLab CI，在代码提交阶段自动触发静态扫描，发现严重异味（Smell）即阻断合并，从而推动团队养成高质量编码习惯。

重构文化与实践建议

除了技术层面的操作，重构还需要团队文化的支撑。

1. 代码审查（Code Review）： 在 Merge Request 或 Pull Request 环节，强制要求包含重构相关的说明。鼓励团队成员互相指出潜在的异味。
2. 技术债务管理： 将重构任务纳入 Sprint 规划，预留一定比例的时间（如 20%）专门用于偿还技术债务，而不是等到系统崩溃才处理。
3. 文档同步： 重构涉及接口变更或逻辑调整时，务必同步更新 API 文档和设计文档，避免信息孤岛。

总结

这篇文章并没有穷尽重构的所有内容，更多的重构清单和实例，请参考鲍勃大叔编写的《代码整洁之道》（Clean Code)，尤其是第 17 章的味道与启发（Smells and Heuristics）和马丁·福勒（Martin Fowler）编写的重构（Refactoring）一书。不管你打算以哪本书为主，在实践过程中，都会殊途同归——沉淀出几条简单的规则。

不要专门花费大量的时间去进行重构，利用小块时间，每次只做一部分，只要保证代码质量比之前有进步就可以了。不要想着以后再做，这个以后很可能是永远不，最终你将面对一系列可怕的遗留代码，然后你就深刻理解了'出来混迟早是要还的'这句话的涵义。

通过持续的微重构，我们可以保持系统的健康度，降低维护成本，提升开发效率。记住，优秀的代码不是写出来的，而是改出来的。