当问题诊断告一段落，很可能你已经完成了任务中最困难的部分了，但是，依然要小心，你必须知道，对于一个好的修复来说，不仅仅是让软件能够正常运行，你还需要为将来奠定良好的基础。
缺陷修复的三个目标：修复问题，避免引入回归，维持或提高代码的整体质量（可读性、架构、测试覆盖率等）
假设你的开发过程包括测试驱动（测试优先）开发，你拥有一个自动化测试框架和大量的单元测试工具，当你要对源代码进行修改的时候，这种方法确实能收到良好的效果，不仅可以用它来确保你的修复程序会解决此问题，还为它避免卷入回归提供了很好的保障。
测试优先开发规则之一：直到有一个失败的测试时，才应该更改源代码。因此，你需要证明你已经拥有了通过所有测试套件作为坚实的基础，同时最好确保有一个失败的案例。
再设计修复方案之前，确保已经知道如何进行测试。
修复问题产生的原因，而不是修复现象
重构是改善既有代码的设计而不改变其行为的过程。修复缺陷往往不会设计重构。你正在使用的代码中包含缺陷，这一事实本身往往意味着代码本应得到更简洁或更好的构建，你很有可能会找到哪些代码能够改进。
执行这些重构和修复缺陷同样重要，有时候在修复缺陷之后再重构比先重构再修复更合理。但是记住：重构的同时绝不能改动代码功能，同样也不能修复有缺陷的代码。
从调试的角度来看，源代码控制的主要价值是审核记录，原则：一次逻辑修改只做一次签入。
代码审查没有固定的执行时间，无论什么时候遇到不确定性或有风险的区域，都要做审查。
成功地修复缺陷是一个伟大的里程碑，但它并不意味着结束。着手下一个任务之前，花点时间思考第一次缺陷是如何出现在软件里的，别的地方的其他实例是否也有相同的问题呢？它可能再次发生么……下一章，我们将一起走进反思的世界~