声明：本文档的内容主要来源于书籍《软件调试修炼之道》作者Paul Butcher，属于读书笔记。欢迎转载！
修复缺陷
对于一个好的修复来说，不仅仅是让软件运行正确，还需要为将来奠定基础。一些列零散的未经仔细考虑的修改，都将是原本的简洁设计逐步消失。
好的修复必须同时实现以下目标：
- 修复问题
- 避免引入回归
- 维持或者提高代码的整体质量
-----------需要参考的规则如下----------
1、清除障碍
- 确保一切从头开始，当你不舍得抛弃诊断阶段所做的修改时，利用源码控制系统。
- 需要对所做的修改进行快速审核，不要跳过这一步！
- 随时做记录，或者保留相关文件的副本。
2、测试
- 如果开发过程包括测试优先（测试驱动）开发，因此你拥有一个自动化测试框架和大量的单元测试工具，修改源码时，这种方法在避免引入回归方面能够收到良好的效果。
- 运行现有的测试程序，并证明它们能够通过
- 添加一个或者多个新的测试程序，后者修复现有的测试程序
- 修复缺陷证明你的修复起了作用（以前的失败不再出现）
- 证明没有引入任何回归（以前通过的测试现在都没有失败）
3、修复问题产生的原因而非修复现象
实际工作中，非常时期，一边是客户愤怒的大声叫嚷，一边是项目经理不耐烦的脸色，你可能就迫于压力只是让缺陷消失，然后进行下一个任务；或者是因为你分析的远远不够，也会导致仅仅修复现象，而非原因。无论这么做多么不好，起码你了解根本原因，并且采取了一个“明智”的办法迅速解决了问题。但是这个办法只是修复缺陷的三个目标之一，后两者更加重要。此时要发挥学术真诚的精神，如果不能确信自己真正理解了问题的症结，就不要相信你的修复！
4、重构
最近几年，随着敏捷开发方法的日益普及，最显著的两项技术的广泛应用就是自动化测试和重构技术。 重构是改善既有代码设计而不改变其行为的过程，具体参考《重构：改善既有代码的设计》。
修复缺陷往往不涉及重构，但是如果缺乏经验的话，为修改缺陷而做出的必要修改时会产生重复，这是不该有的，这就是《程序员修炼之道》一书中描述的“不要重复你自己”的原则。
在修复缺陷之后重构比先重构再修复更合理，当然，如果修复工作很复杂，可能要反复经历修复和重构的过程！
切记：重构的同时不可改动代码功能，同样也不能修复缺陷！
5、签入
要合理利用源码控制系统，如果将很多错误集合起来一起签入，就会大大降低其作用
请坚持这项原则：一次逻辑修改只做一次签入
6、代码审查
代码审查没有固定执行时间，有时让同事参与修复的初期阶段，有时只是让其签字确认！该方法是开发过程固有的一部分，而不必看成一个很正式的调试方法！