声明：本文档的内容主要来源于书籍《软件调试修炼之道》作者Paul Butcher，属于读书笔记。欢迎转载！

修复缺陷

对于一个好的修复来说，不仅仅是让软件运行正确，还需要为将来奠定基础。一些列零散的未经仔细考虑的修改，都将是原本的简洁设计逐步消失。

好的修复必须同时实现以下目标：

• 修复问题
• 避免引入回归
• 维持或者提高代码的整体质量

-----------需要参考的规则如下----------

1、清除障碍

• 确保一切从头开始，当你不舍得抛弃诊断阶段所做的修改时，利用源码控制系统。
• 需要对所做的修改进行快速审核，不要跳过这一步！
• 随时做记录，或者保留相关文件的副本。

2、测试

• 如果开发过程包括测试优先（测试驱动）开发，因此你拥有一个自动化测试框架和大量的单元测试工具，修改源码时，这种方法在避免引入回归方面能够收到良好的效果。
• 运行现有的测试程序，并证明它们能够通过
• 添加一个或者多个新的测试程序，后者修复现有的测试程序
• 修复缺陷证明你的修复起了作用（以前的失败不再出现）
• 证明没有引入任何回归（以前通过的测试现在都没有失败）

3、修复问题产生的原因而非修复现象

实际工作中，非常时期，一边是客户愤怒的大声叫嚷，一边是项目经理不耐烦的脸色，你可能就迫于压力只是让缺陷消失，然后进行下一个任务；或者是因为你分析的远远不够，也会导致仅仅修复现象，而非原因。无论这么做多么不好，起码你了解根本原因，并且采取了一个“明智”的办法迅速解决了问题。但是这个办法只是修复缺陷的三个目标之一，后两者更加重要。此时要发挥学术真诚的精神，如果不能确信自己真正理解了问题的症结，就不要相信你的修复！

4、重构

最近几年，随着敏捷开发方法的日益普及，最显著的两项技术的广泛应用就是自动化测试和重构技术。 重构是改善既有代码设计而不改变其行为的过程，具体参考《重构：改善既有代码的设计》。

修复缺陷往往不涉及重构，但是如果缺乏经验的话，为修改缺陷而做出的必要修改时会产生重复，这是不该有的，这就是《程序员修炼之道》一书中描述的“不要重复你自己”的原则。

在修复缺陷之后重构比先重构再修复更合理，当然，如果修复工作很复杂，可能要反复经历修复和重构的过程！

切记：重构的同时不可改动代码功能，同样也不能修复缺陷！

5、签入

要合理利用源码控制系统，如果将很多错误集合起来一起签入，就会大大降低其作用

请坚持这项原则：一次逻辑修改只做一次签入

6、代码审查

代码审查没有固定执行时间，有时让同事参与修复的初期阶段，有时只是让其签字确认！该方法是开发过程固有的一部分，而不必看成一个很正式的调试方法！