2018-05-27

《调试九法》读书笔记

《调试九法》读书笔记

最近一周在读的一本书是《调试九法》，看完此书之后，感觉这就是一本调试界的葵花宝典，虽然作者并不是互联网行业的一员，书众所列举的例子我也不会遇到，但是这套调试方法看下来之后，却有很多共鸣之处，就像书中说的“本书适用于任何人”。

对于这些调试规则，以下我将他们结合到我的行业中，结合自己的思考，整理一下，便于加深理解和以后的二次阅读。

调试规则：

一：理解系统

二：制造失败

三：不要想，而要看

四：分而治之

五：一次只改一个地方

六：保持审计跟踪

七：检查插头

八：获得全新观点

九：如果你不修复 bug，它将依然存在

一：理解系统

我认为调试方法中首要的一个规则就是”理解系统“，没有理解原理之前，很多问题都没有办法去调试。除非是那种显而易见的。

对于平时的 bug 而言，一般情况下分配给自己处理的都是自己所写的逻辑模块的 bug，因此对于那部分的系统来说，是最清楚不过的（当然，假如那个系统是你 N 年前写的东西，估计还需要你再去梳理一下），但是某些情况下也是不尽然的。在这种你需要去修复别人写的东西的 bug的时候，此规则就是你必须去做的了，永远不要犹豫要不要去做这件事，做就是了。

二：制造失败

在 QA 同学提出 bug 之后，我们首先要去“制造失败”。这是我每次接到 bug 之后，肯定会做的一个步骤，尝试去复现 bug，假如这个 bug 每次必现，我会很开心。最起码不需要再去反复和 QA 同学确定细节，要知道，反复确定细节的结果有可能是无用功，并不会提供多大的帮助。

对于一些比较难“制造失败”的 bug，就需要考虑是不是应该去做点什么，让这个 bug 复现的更方便。

说到这就让我想起了之前遇到的一个 bug，那个 bug 不是规律性复现，我每次尝试“制造失败”的时候，都要一遍一遍的重复操作，企图以最快的速度去复现这个 bug，虽然这个方式也是能复现的，但是那个下班之后回到家的夜晚，我的肩膀异常的疼痛，我把这个锅都扔给了这个 bug，却没有意识到是我“制造失败”的过程太艰辛。还是多亏了同事的提醒，我写了一个自动测试工具，代替了我的人工点击，几分钟的工作，直接的结果就是“制造失败”效率提高了，节省了时间，让我能专心在观察 bug 上，并且胳膊也解脱了。

所以在复现问题的过程中假如太麻烦的话，请考虑花几分钟去写个测试工具，你肯定会感谢你自己做的这个决定。

关于书中所说到的“不要模拟失败”，在看的过程中还是有一些疑惑的。引发失败（正确）和模拟失败（错误）这二者之间存在着非常大的差别。对于那种为了排除干扰因素，建立一个小工程去把不相关部分去掉，只单单观察核心的方式，其实并不是“模拟失败”。“模拟失败”的意思是模拟失败机理本身。

三：不要想，而要看

在遇到 bug 之后的一大忌就是直接去怀疑是哪里出的问题，“不要想，而要看”，去确确实实的看到问题是怎么产生的，猜疑是最不可靠的。假如从一开始你就认为这个 bug 一定是某个部分出了问题，那你从一开始就被蒙蔽了双眼，你会戴着有色眼镜去看这个问题，会产生误导，引入歧途。

需要去看到失败是怎么发生的，在哪里发生的，然后去调试，看到是哪里出了问题，顺藤摸瓜，找到问题的源头，从而解决问题。

当然，”不要想，而要看“并不意味着不能做任何猜想。当理解了系统之后，猜测可能很接近事实，但猜测只是为了确定搜索的重点。在尝试修复问题之前，仍需要再次看到失败，以便确认猜测的是正确的。

四：分而治之

这个规则也是调试过程中一个重要的规则。首先要缩小搜索范围，确定出错的大概范围。书中说了一个小游戏，让你的朋友从1-100之间选一个数字，由你来猜，每次你的朋友告诉你是猜高了，还是猜低了，最多只需7次你就会猜到答案。采用二分法的思路，每次猜区域中间的数字。我和我的朋友玩了这个游戏，恰巧的是，我真的花了整整七次，猜到了他的答案（他的答案是66）。任何有效的目标搜索都会使用一种共同的技术，那就是”逐次逼近“。

还有就是当你去查找这个 bug 的过程中，假如发现了别的 bug ，需要先去修复那个已知 bug，有可能正是这个已知 bug 导致了那个 bug，我在工作的过程中也经常会遇到这样的情况，很多时候，修复了已知的 bug，原 bug 也就迎刃而解了。

五：一次只改一个地方

修复 bug 的时候，一次只改一个地方，在你尝试修复这个 bug 的过程中做的任何尝试性改动都要记得及时恢复。不要看到哪里觉得写的不太好，就尝试着去做改动，有可能你的这个改动对修复 bug 来说没有一点帮助，相反，有可能还会引入新的问题，造成覆盖掉了原 bug。

要保证一次只改一个地方，版本管理就显出价值了。你可能需要和正常系统进行比较，可能这个 bug 是之前没有发生过的，那就需要回到正确的版本，去对比查看这期间做了什么改动。这对于无思路的情况下是一个很有帮助的方法。能直观的看到自从上一次能够正常工作依赖更改了什么导致这个 bug 的产生。

六：保持审计跟踪

这个规则可能需要在 QA 同学的协助下进行，需要记下每步操作、顺序和结果。还要注意记下细节，找出关联。

但是这个规则在 QA 同学不能给出足够多细节的时候还是要靠自己，去”制造失败“，发现问题。并且不要过分的对自己的记忆自信，现实往往是打了自己的脸。好记性不如烂笔头，记下来，不仅是对后人的负责，也是对自己的负责。

七：检查插头

这个规则是针对一些最单纯的问题，但是我们往往会直接忽略掉，自动默认是正确的情况下。例如机器不能工作，没准就是你的机器插头松掉了而造成。对于这种情况，假如我们做了一大番研究之后，最后才查出是这种原因的时候，估计我们心中只会苦笑。

所以，要从头开始检查。查看各方面条件是否都正确，不错过任何一个细节，不要想当然。

八：获得全新观点

当你对一个 bug 没有头绪的时候，你可能需要一个比你更加了解，更加有经验的人，来向他寻求一下帮助，获得一个你自己想不到的全新观点，借鉴别人的经验，能让你少走弯路，豁然开朗。

应用这个规则的时候，需要注意的一点是，在向别人寻求帮助的时候，只报告症状，而不要阐述你自己的理论。之所以要从别人那里获得全新的观点，就是因为你的理论起不到任何作用。假如你把你的理论告诉他，那么也会把他拉到你原来的思维定势中，同时，你很有可能会把一些需要让他知道的关键细节隐藏起来，因为你自己有偏见，认为这些细节不重要。但是你这么做的结果就是，你可能并不能获得全新观点，失去了一个解决 bug 的机会。