声明：本文档的内容主要来源于书籍《软件调试修炼之道》作者Paul Butcher，属于读书笔记。
不要急于动手！
尽管可以利用各种工具和技术以及软件自身查找缺陷，但是你最重要的财富是你的智慧
- 一种调试方法
提出假设->设计实验->假设不成立，重新开始
- 采用不同类型的实验
进行几种不同类型的实验，但是每种实验必须有一个明确的目标。比如软件内部运行状态、软件的输入参数、本身编码逻辑。
- 实验必须起到验证的作用
实验是一种达到目的手段，而不是目的的本身。可以通过实验用来证明或者推翻假设。
- 一次只做一次修改
设计实验的规则之一，你每次只能做一个修改。此规则适用于任何修改，令人大跌眼镜的是，该规则经常被人忽略！虽然一次修改几个地方看起来省时间，实际上可能得到的只是无效的结果。不要再犯这种错误
- 记录你所做过的调试
在长期调试时，由于做过多种实验，最后可能忘记自己做了哪些工作，并且在已经得到证明的问题上重复浪费时间，甚至进入死胡同。因此应该做调试记录，理想情况是每个实验都都消除一些可能原因，最终找到根本原因。
- 不要忽略任何细节
凡是你不明白的都是潜在的缺陷，因此即使莫名其妙的现象，也往往对发现问题本身非常有价值。弄清楚意想不到的运行状况可以为你节省大量跟踪缺陷的时间。
相关策略
- 插桩
留意海森堡定律，其本身不应该影响软件本身的运行，有充足的利用把插桩留到代码中，从而编写出自调试软件。
- 分而治之
也就是二分法，这种方法可以排除很多错误的情况，提高效率，但是对减小工作量、提高效率，其并非唯一。
- 利用源码控制工具
利用源码控制系统，可以进行有效的回归跟踪，它可以有效的告诉你哪个变化导致了这些问题。
- 聚焦差异
问题是否只在特定环境下重现？是否在大量数据输入情况下重新？
- 向他人学习
许多缺陷只存在于代码中，因此只有你和合作者才能解决它们。但有时其设计到特定的算法、库文件等，这种情况可能其他人已经遇到过同样的问题。
陷阱
下面这些是从实战中来之不易的经验教训
- 你做的修改正确吗
如果修改没有起到任何效果，那么你并没有改到点子上。这个陷阱很容易掉进去，又让人摸不着头脑，唯一的防御措施是时刻提高警惕。
- 验证假设
假设会带来盲点，要了解你正在做什么样的假设，以及何时对它进行严格的检验。
- 多重原因
这种情况比较难，最富有成效的解决多原因缺陷的办法是对问题进行隔离，并找到一个方法来重现缺陷。另外一个方法是先找寻同一区域内其它明显的缺陷并处理。
- 流沙
实证方法的基础是，可以一次一次的重现问题，并且每次获得相同的结果，但是如果没有了这种确定性，想取得改进就变得极为困难。如果自己遇到了这种问题，那就立即停下来，继续进行只会陷入更大的麻烦。此时的主要目标是准确的找到是什么在变化，以便你能控制它。
思维游戏
调试是艰苦的，有时简直苦不堪言，别灰心 ，我们都遇到过。这正是软件开发工作的 一部分，如果你遇到这种情况，下面的技巧会帮你解决这些问题。
- 旁观调试方法
最有效的一个策略就是向人求助，人多力量大，问题可能很快得到解决。做过这项工作的人都知道，往往只要把问题再解释一遍的简单行为也能激发灵感。因此实在找不到人，对着橡皮鸭或者纸人都可以做。
- 角色扮演
在解释和探讨问题时非常有用，特别是涉及到系统之间的数据交互时。
- 换换脑筋
当自己变得沮丧或者超负荷时，休息一会，看问题的角度可能就大不相同。
- 做些改变
当做实证实验陷入困境之中时，做一点改变是必要的，任何改变都可以，也需不会告诉你任何东西，但是有时会给你带来惊喜。
- 福尔摩斯原则
当你排除了一切不可能，无论剩下的是什么，他也一定是真相！
- 坚持
在绝望时，请记住总有一个办法能帮你解决问题，只要有足够的时间、付出足够的精力和决心，你一定会解决问题。
验证诊断
我们人类是多才多艺的，其中才能之一就是自欺欺人。考虑到这一点，花时间验证你的诊断是很值得的。
- 向他人讲述你的诊断
他们可能会发现一个缺陷，即使是旁观者效应也能帮助你达到这样的效果。
- 检查源码原始副本
从一个已知没有问题的版本重新验证你编程时的思考。
- 多和他人讨论
假设你是错误的，知道你犯过什么错误了吗？