<读书笔记>软件调试之道 ：问题的核心-诊断

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

不要急于动手！

尽管可以利用各种工具和技术以及软件自身查找缺陷，但是你最重要的财富是你的智慧

• 一种调试方法

提出假设->设计实验->假设不成立，重新开始

• 采用不同类型的实验

进行几种不同类型的实验，但是每种实验必须有一个明确的目标。比如软件内部运行状态、软件的输入参数、本身编码逻辑。

• 实验必须起到验证的作用

实验是一种达到目的手段，而不是目的的本身。可以通过实验用来证明或者推翻假设。

• 一次只做一次修改

设计实验的规则之一，你每次只能做一个修改。此规则适用于任何修改，令人大跌眼镜的是，该规则经常被人忽略！虽然一次修改几个地方看起来省时间，实际上可能得到的只是无效的结果。不要再犯这种错误

• 记录你所做过的调试

在长期调试时，由于做过多种实验，最后可能忘记自己做了哪些工作，并且在已经得到证明的问题上重复浪费时间，甚至进入死胡同。因此应该做调试记录，理想情况是每个实验都都消除一些可能原因，最终找到根本原因。

• 不要忽略任何细节

凡是你不明白的都是潜在的缺陷，因此即使莫名其妙的现象，也往往对发现问题本身非常有价值。弄清楚意想不到的运行状况可以为你节省大量跟踪缺陷的时间。

 

相关策略

• 插桩

留意海森堡定律，其本身不应该影响软件本身的运行，有充足的利用把插桩留到代码中，从而编写出自调试软件。

• 分而治之

也就是二分法，这种方法可以排除很多错误的情况，提高效率，但是对减小工作量、提高效率，其并非唯一。

• 利用源码控制工具

利用源码控制系统，可以进行有效的回归跟踪，它可以有效的告诉你哪个变化导致了这些问题。

• 聚焦差异

问题是否只在特定环境下重现？是否在大量数据输入情况下重新？

• 向他人学习

许多缺陷只存在于代码中，因此只有你和合作者才能解决它们。但有时其设计到特定的算法、库文件等，这种情况可能其他人已经遇到过同样的问题。

 

陷阱

下面这些是从实战中来之不易的经验教训

• 你做的修改正确吗

如果修改没有起到任何效果，那么你并没有改到点子上。这个陷阱很容易掉进去，又让人摸不着头脑，唯一的防御措施是时刻提高警惕。

• 验证假设

假设会带来盲点，要了解你正在做什么样的假设，以及何时对它进行严格的检验。

• 多重原因

这种情况比较难，最富有成效的解决多原因缺陷的办法是对问题进行隔离，并找到一个方法来重现缺陷。另外一个方法是先找寻同一区域内其它明显的缺陷并处理。

• 流沙

实证方法的基础是，可以一次一次的重现问题，并且每次获得相同的结果，但是如果没有了这种确定性，想取得改进就变得极为困难。如果自己遇到了这种问题，那就立即停下来，继续进行只会陷入更大的麻烦。此时的主要目标是准确的找到是什么在变化，以便你能控制它。

 

思维游戏

调试是艰苦的，有时简直苦不堪言，别灰心 ，我们都遇到过。这正是软件开发工作的 一部分，如果你遇到这种情况，下面的技巧会帮你解决这些问题。

• 旁观调试方法

最有效的一个策略就是向人求助，人多力量大，问题可能很快得到解决。做过这项工作的人都知道，往往只要把问题再解释一遍的简单行为也能激发灵感。因此实在找不到人，对着橡皮鸭或者纸人都可以做。

• 角色扮演

在解释和探讨问题时非常有用，特别是涉及到系统之间的数据交互时。

• 换换脑筋

当自己变得沮丧或者超负荷时，休息一会，看问题的角度可能就大不相同。

• 做些改变

当做实证实验陷入困境之中时，做一点改变是必要的，任何改变都可以，也需不会告诉你任何东西，但是有时会给你带来惊喜。

• 福尔摩斯原则

当你排除了一切不可能，无论剩下的是什么，他也一定是真相！

• 坚持

在绝望时，请记住总有一个办法能帮你解决问题，只要有足够的时间、付出足够的精力和决心，你一定会解决问题。

 

验证诊断

我们人类是多才多艺的，其中才能之一就是自欺欺人。考虑到这一点，花时间验证你的诊断是很值得的。

• 向他人讲述你的诊断

他们可能会发现一个缺陷，即使是旁观者效应也能帮助你达到这样的效果。

• 检查源码原始副本

从一个已知没有问题的版本重新验证你编程时的思考。

• 多和他人讨论

假设你是错误的，知道你犯过什么错误了吗？