调试九法读书笔记

1.如果一个bug花了非常长的时间，那么原因可能是忽略了某个最基本的、最重要的规则，一旦应用了那条规则，很快就会找到问题。

2.善于调试的人已经深刻理解了这些规则，那些很难理解和使用这些规则的人则很难找到bug。

3.规则1，理解系统；规则2：制造失败；规则3：不要想，而要看；规则4：分而治之；规则5：一次只改一个地方；规则6：保持审计跟踪；规则7：检查插头；规则8：获得全新观点；规则9：如果你不修复bug，它将依然存在。

 

理解系统

1.当所有方法都不管用的时候，读读指令。

2.首先阅读手册，理解系统修复bug时不破坏系统的第一步。

3.可以暂时忽略图表，但是数据表一定要仔细阅读。

4.检查Bug的时候，要明确系统正常工作时候的状态，输入输出等。

5.如果不知道时钟选中的脉冲和地址线的作用，那么就无法理解中断是干嘛的，需要掌握工作领域中的基础知识。

6.寻找bug的时候，需要明确查找路线，大体需要知道系统中的模块和接口是干嘛的。他们之间交换的是什么数据，每个模块和接口内部是如何处理的。

7.当某个模块式黑盒时，需要明确他的交互，确定是盒子内部还是外部的bug。

8.要熟练掌握调试工具以及工具的设置和细节。了解编译器和链接器是如何处理代码的。数据匹配，引用处理，内存分配都是会对程序早成影响的。

9.不要猜测，而要查阅手册！

 

制造失败

1.要观察错误，就必须使它发生。而且要尽可能的使它有规律的发生。

2.准确的知道问题在什么情况下会发生，然后再去集中精力解决它。

3.要能够确定bug已经修复，例如执行操作x出错100%，修复之后执行x出错为0.（个人理解：有时候修复一个Bug的时候，还会引起别的操作例如y操作出现bug）

4.仔细观察出错之前自己做了什么，并记录下来，在按照所写的步骤做一次。

5.要从一个自己确定的已知状态出发，即使bug在经历很复杂的步骤之后才会出现。

6.如果bug只有在重复多次的情况下才会出现，那么尽量实现自动化，让软件自己运行在这种重复的状态下，自己集中精力去观察bug。例如网络在高流量下发生错误，就该下载一个网络加载工具来模拟负载引发错误。

7.模拟失败发生的条件，而不是模拟失败本身的机理。否则永远调试不出来。

8.利用工具来观察发生了什么错误，不要去改变错误发生的机理，不要去另一个类似的系统上再现bug，因为类似的系统可能会因为细微环境的差别导致引起bug的原因不定。就是不要用看似完全相同的环境来替代期望看到相同的错误。

9.处理间歇性的bug，需要查明未初始化的数据，随机输入值，多线程的同步工作，时序误差和外设。在硬件中，需要查找振动、温度、噪声和部件误差等。

10.一旦想到了哪些条件可能影响自己的系统，要大量的去尝试这种条件下系统的反应，要见这些条件按照已知可控的方式作为系统的输入。

11.如果找不到失败的原因，那就尝试找到失败发生的条件，例如增加噪声，增大随机输入值，当某个条件的放大使得间歇性的bug成为一直发生的bug的时候，那么沿着这个条件去找就可以了。

12.要学会利用系统输出和调试日志，这有助于帮助观察间歇性的bug。

13.麦冰激凌和汽车发布发动得起来的问题。要找到隐藏在现象背后的机理。

14.制造失败、从头开始、引发失败但不要模拟失败、查找不受你控制的条件、记录每件事情并找到间歇性bug的特征、不要过于相信统计数据、要认识到“那”可能是会发生的、永远不要丢掉调试工具。

 

不要想，而要看

1.起眼看到底层的错误是非常重要的，如果仅仅是猜测，那可能会修复一些根本不是Bug的问题。不要想，而要看。

2.观察其实是很困难的，除了设置端点、添加调试语句、监视程序运行中的变量和地址值、检查内存，尤其是在需要借助逻辑分析仪这样工具的时候。

3.观察的程度要在把Bug定位在几种可能的范围之内。

4.要学会把工具植入到系统中进行观察。例如在硬件方面把所有寄存器设置为可读可写的，添加LED和状态显示器，植入传感器。软件方面，将系统编译为调试模式，或者使用例如var watch这样功能的软件。总是，就是要获得更多的输出！可以借助debug宏。

5.在做以上插装步骤的时候，要保证自己调试环境和Bug出现的环境一致。因为调试输出可能会影响系统的性能，进而影响bug出现的条件。

6.选择调试输出的内容应该能够证实你的判断，或者显示出你从未意料到的状况。

7.添加外部插装，调试硬件的时候可以使用万用表、示波器、逻辑分析仪、热电偶等等。软件可以使用调试总线的分析器、反汇编工具等。

8.仅仅有的猜测那边是为了确定要搜索的重点目标！

9.观察失败、查看细节、植入插装工具、添加外部插装工具、不要害怕深入研究、注意海森堡效应（总有一个测不准）、猜测只是为了确定搜索的重点。

 

分而治之

1.重新装配是绝对必要的，或者说重启是必要的，因为这样才能检测问题有没有被具体修复。

2.要反复的把问题分成好的一般和坏的一半，缩小范围，然后分而治之。

3.缩小搜索范围，逐次逼近。

4.将整个系统作为搜索的起始点，先确定是硬件问题还是软件问题。

5.确定是目前搜索的范围是在好的一半还是坏的一半。

6.在搜索的范围内，如果效果不易于观察，就插入易于识别的模式或者输入流。打比方正常情况下数据流好比河水，浑浊不清，看不到哪些好的哪些坏的，那就把有颜色的水倒进去，看他如何流向。（话说能制造这种易于识别的模式也是需要能力的，例如自己构建程序，搭建电路等）

7.从分支开始查找问题，不要从好的源头开始，因为正确的东西太多，顺着分支往上摸。

8.有时候我们查找问题A的时候，发现还存在问题B和C，这时候需要在确定问题B和C之后，立刻修复他们，然后再去修复查找和修复A。有时候等你修复了B和C你会发现A已经自动修复了。

9.首先消除噪声的干扰，在软件中，噪声是指较差的多线程同步，未初始化的变量和意外的可重入函数。

10.通过逐次逼近缩小搜索范围、确定范围、确定你位于bug的哪一侧、使用易于查看的测试模式、从有问题的一端开始搜索、修复已知的bug、消除噪声干扰。

 

一次只改一个地方

1.当你在修复bug的时候，如果改动了一个地方，一定要记录，当你修复了真正错误的地方的时候，也许因为你之前修改的地方系统还是无法工作，这是就会造成没有修复的错觉。有种笨的办法就是修改一次之后就看效果，如果不行，就改回到原来的状态。

2.控制其他变量全部都一样，只更改需要研究的地方。

3.在保证其他条件一致的情况下，使用一个引发失败的例子，一个正常的例子，查看输出，而且不要更改太多的代码来对比，不要使用不同的机器、软件、参数和用户输入。

4.记住自从上一次能够正常工作以来修改了什么。找出第一个导致系统出错的版本，与前一个正常的版本进行比较，将错误限定在这两个版本修改过的范围内。

5.有时候，bug是长期存在的，只是因为你改动了一个地方使得它暴露了出来。

6.隔离关键因素，在你不知道具体发生了什么问题的情况下不要急着去修复，一次只改一个地方然后去测试，与正常情况进行比较，确定自从上一次正常工作以来修改了什么地方。

 

保持审计跟踪

1.需要记录下每一个细节，有些时候不起眼的东西对调试还有很大的帮助。

2.保持审计跟踪，在检查bug的时候，记录下所做的事，做事的顺序以及发生的结果。

3.做测试，发现Bug的时候，需要将事情的描述具体且一致，并且要记录问题的严重程度。

4.要学会关联思维，将某些症状或者调试信息关联起来是非常有用的，例如线路刚刚接通会发出很大的噪声这样的描述不如：线路在接通时发出很大噪声，从14:05:23持续4S到14:05:27之间。

5.用于设计的审计跟踪在测试中也非常有用，记录每个版本都做了什修改。

6.好记性不如烂笔头，把自己做做的事情和结果记录下来，保存调试和跟踪记录，注明相关的事件和影响，把自己的推理和修复操作以及其他全部内容全部记录下来。

7.把你的操作、操作的顺序和结果全部记录下来。要知道哦、任何细节都可能是重要的。把事情关联到一起。用于设计的审计跟踪在测试中也非常有用。把事情记录下来。

 

检查插头

1.如果忽略了一些基础性问题的可能性，那么有时候肯定会遇到一些非常尴尬的场面。

2.怀疑自己的假设，永远不要相信自己的假设，也被是当这些假设在一些无法解释的问题中是核心因素的时候，就应该反问自己一个古老的、看似愚蠢的问题。

3.从头开始检查，运行之前是否初始化，启动条件有时候是正确的，开关打开没，内存初始化没等等。

4.编译器工具，尤其要查看编译选项，因为有些代码本身并没有bug，因为编译器的默认选项和环境的不同导致最终的运行结果不一致，这就需要将一些自认为默认的东西显示的表达出来。（况且编译器也是软件，也会存在bug）

5.深信不疑是真理的可怕敌人，甚至比谎言更为可怕。

6.置疑你的假设。从头开始。对工具进行测试。

 

获得全新的观点

1.向该领域有经验的专家请求帮助，获得更加快速的解答。但要找对人，不要找那些跟你吹嘘时髦理论的“江湖郎中”。

2.获得全新的观点，我们按照自己的老一套的思路很那看清全局，偏见导致我们无法看清实际情况，而其他人则会从另外一个角度看待问题。所以有时候遇到问题可以请教他人，在向别人解释问题的时候，也许自己就能跳出原来的模式，将思路理清，从而解决问题。

3.向有经验的人求教，如果有维修指南或者FAQ这样的文档，遇到问题一定要去阅读。

4.要知道向什么人求助，第三方供应商，wiki，论坛，翻墙等。学会查阅资料的本事。

5.向别人求助的时候，不要报告自己的理论，因为这样会把别人也带到自己的理论中来，要报告症状，描述发生的事情就行。

6.即使不是十分肯定，也可以提出来。

7.征求别人的意见、获取专业知识、听取别人的经验、帮助无处不在、放下面子、报告症状而不要讲你的理论、提出的问题不必十分肯定。

 

如果你不修复BUG，它将依然存在

1.检查确实是修复措施解决了问题，修复之后一定要验证，并且是可靠的验证。在你修改的和原来的之间切换，反复测试系统是否不正常与正常。因为你修复的过程中可能改变了其他因素。

2.bug从来不会自己消失，要从根本上解决问题，并知道问题出在哪里，如何修复的。

3.即使拿到了一个新的和原来一模一样的模块，也要测量一下他是否符合系统的工作要求。

4.要根据bug追踪设计过程的缺陷，在下一个版本中，去修复这个过程。

5.查证问题确实已经被修复。Bug从来不会自己消失。从根本上解决问题。对过程进行修复。