调试debug九法读书笔记|软硬件错误的排查之道|解决问题

来源

彭思达老师的科研经验

原文pdf

通过网盘分享的文件：调试九法.pdf
链接: https://pan.baidu.com/s/1oZv0YJg1ElGtqkC3daygrg?pwd=tsjf 提取码: tsjf
--来自百度网盘超级会员v5的分享

用9条原则，把调试艺术转化为科学

【我这里是把原则和看起来重要的信息展示出来了，但是其实里面的故事也很重要，有兴趣读故事的话把pdf看了吧】
关键是记住并应用这些规则。记住它们，知道它们的益处，掌握如何运用它们。
适用于任何人，无论是工程师、程序员、技师、客户支持代表还是顾问。
不必理解所使用的系统和工具的细节，因为这些都是基本的规则，可以帮你更快地解决问题。
本文讲的都是通用的技术，可以帮你找到任何问题，也适用于修复各类问题，如系统设计、构建和使用中有错误，或被破坏了。
不局限于工程领域，可以帮忙查找其他方面的问题，如汽车、房屋、音响、管道，甚至是身体。当然经济学太复杂了，不适用。
书的主旨是：查找bug的根源并修复。
如何准备查找bug，如何挖掘并仔细审查各种线索，以便找到根源，追踪实际问题，并修复它，然后确认已经修复问题，可以去玩啦！
调试的定义：查明为什么一个设计没有按计划工作。不关心问题是怎么产生的，而是找到问题在哪里。

1 理解系统

【最重要的规则】
在理解工作原理之前，其实无法对问题进行调试。而一旦理解了原理，问题就显而易见了。系统的主要部分都理解，是一件非常重要的事情。
但更重要的事情是，需要掌握系统的工作原理以及它是如何设计的，在某些情况下，还要知道为什么是这样设计的。有必要的话，仔细研究所有的细节。
如果没有理解系统中的某个部分，这通常就是出问题的地方。当然理解系统不等于理解问题。
总之，如果想要查明系统为什么不工作，就要理解工作原理。
【1）阅读手册】
基本方法！首先就要阅读手册，而不是等所有办法都不管用后，才去读它。
对工程师，调试公司自己的产品，要读内部手册。知道工程师设计它是用来做什么的，读功能说明和设计规范，读代码及其著是，检查产品的设计。知道构建它的工程师打算用它做什么。
不过手册上的信息也不全可信，手册可能是错的，这也可能是bug的来源。但是依然需要读手册，了解其设计。
找到bug后，需要在不破坏其他地方的前提下修复它们，而理解系统是不破坏系统的第一步。
【2）逐字逐句阅读整个手册，仔细阅读每个细节】
编程指南和API可能非常厚，必须深入挖掘，查找你觉得有问题的函数。图标部分可忽略，数据表要仔细看，可能不起眼的一行就是问题所在。
应用说明和实现指南提供了丰富的信息，包括系统如何工作，也讲了之前发生过的问题。常见的错误警告有难以置信的价值（哪怕犯的错误不常见）。
参考设计和程序样本只是产品的一种使用方式，但使用设计时要注意，创建它们的人往往只了解自己的产品，不一定遵循好的设计实践，或者不是为真实应用设计的。
因此不要照搬这些设计，避免出现bug。哪怕是最好的参考设计，也不一定能完全符合应用程序的特定需求，所以多自己动脑子设计吧！
【3）掌握基础知识，知道什么是正常的】
知道什么是正常的，可以帮你注意到什么是不正常的。所以需要掌握所工作的技术领域的基础知识，否则就去向有专业知识或经验的人请教。
【4）了解工作流程】
尝试寻找bug时，需要知道查找的路径。开始时需要猜测在哪里把系统分隔开，从而隔离问题。猜测，需要取决于你对系统功能划分的了解，至少要大体知道所有模块和接口都是干啥的，知道系统中所有API和通信接口都是用来交换什么数据的，知道每个模块或程序如何处理通过接口收发的数据。代码若是高度模块化或面向对象的，接口就比较简单，模块也有良好的定义。观察接口可以用来解释看到的东西是否正确。
若系统是黑盒子，那你就不知道其内部有什么。但是，应该知道它们如何和其他部分交互，至少可以用来判断问题在内部还是外部。问题在内部的话，就要换盒子，如果问题在外部，就可以修复它。
【5）了解工具】
调试工具是用来观察系统的，要选正确的工具，正确地使用工具，并且正确解释得到的结果。很多工具有强大的功能，但是只有精通它的用户才了解。越是精通工具，就越容易查明系统中发生的事情。务必花时间学习和工具有关系的一切。查明系统行为的关键是调试器设置情况，或是否正确地触发了分析器。
还需要了解工具的局限性。查源代码可以找到逻辑错误，但是很难显示时序和多线程的问题；分析工具可以查出时序问题，但是显示不出逻辑错误。模拟示波器可以看到噪声，但是没法存储太多数据；数字逻辑分析器可以看到大量数据，但是看不到噪声。
断点也有其局限性。把发生的事情记录下来，通过查看跟踪记录，可以看到程序在什么地方发生了问题。
必须了解开发工具，包括用来编写软件的语言，还要知道更微妙的知识：编译器和链接器在把代码发给机器之前会进行的处理，数据如何匹配，引用如何处理，内存如何分配等等。
【6）查阅细节】
不要猜测，要查阅手册。不要盲目相信自己的记忆，养成良好的查阅习惯。
若单凭猜测去观察信号，看到错误信号时，可能会把它当成正确的。若假定工作是正确的，那么就会把问题忽略，导致信息的混淆，甚至再次确认错误的信息。不要把调试时间浪费在错误的信息上。

2 制造失败

当你发现一个故障时，可以试着让它再次发生
原因：
①可以观察它。观察错误，就得让它发生。所以要尽可能有规律地制造失败。
②可以专心查找原因。准确地知道问题在什么条件下会发生，有助于集中精力查找原因。
③判断是否已经修复问题。如果认为已经修复了问题，如何确定它确定已经被修复，就是要明确问题是如何发生的。问题没修复的话，做X失败率为100%，那么修复问题后如果再做X，失败率为0，就会知道Bug已经被修复了。
【1）制造失败】
如何制造失败？
简单方法：内部预演
有效方法：演示给未来的投资者
设法正常使用，观察其如何出错。测试是使其再错误第一次出现后，能够使其再现。认真记录测试可以作为补充，但只有一次是不够的！
仔细观察做了什么，然后再做一次，记下做的每一个步骤。再按照自己写的步骤去做，确定这样做确实导致了错误。
【2）从头开始】
通常所需的步骤短而少，不过有时候步骤虽简单，但是要做很多设置。
bug可能仅在机器某个复杂状态下才出现，所以要仔细注意机器执行步骤时的状态。
所以从已知的状态开始吧！
【3）引发失败】
调试故障时，要手工执行很多步骤，让这个过程自动化，有帮助。很多时候，在重复很多次后，错误才会出现，所以在夜间运行自动测试工具吧。
若web浏览器有时会打开错误网页，就要设置浏览器让它自动请求，就更好找错误了。若网络软件在高流量下发生错误，就运行网络加载工具模拟负载，引发错误。
【4）不要模拟失败】
引发失败和模拟失败不一样，应该模拟导致失败发生的条件，而非试图模拟失败机理本身。因为猜测可能是错误的，测试也可能改变条件导致模拟系统可以正常工作，或者更糟糕，发生新的错误，分散对现在错误的注意力。
用工具观察发生了什么错误，但不要改变机理，否则可能会导致新的错误。
如果一个bug可以在多个系统上再现，它是设计bug，不是在一种系统上以特定的方式出现。
如果在某种配置下能够再现它，而在另一些配置下无法再现，这就帮我们缩小了查找范围。如果无法快速再现，就不要为了让它出现来改变模拟环境。
否则会产生新的配置，而非原来发生错误的配置。总之无论系统在哪种常规配置下出错，都要在该系统下用该配置找问题。
如果没有相同设备或条件，也不要试图模拟设备，而是把设备运到自己的场地，让工程师调试，或者派工程师到现场调试。
不要用看似完全相同，但是实际上不同的环境来代替，并且希望看到相同的错误。
可以用自动化过程引发失败，自动测试可以使得间歇性问题更快发生；也可以再用一些起到放大效果的措施。
所做的改变应该是一些高层次的改变，只影响错误发生的频率，而不影响错误的发生方式。
另外不要画蛇添足，引发新的问题。
【5）如何处理间歇性bug】
偶然的bug可能难以制造失败。可能频率低，5次10次甚至数百次才出现一次。问题在于要弄清楚失败如何发生。
完整搞清楚失败是如何发生的。知道做了什么，以及没注意到或无法控制的因素，比如说初始条件、输入数据、时序、外部过程、电子噪声、温度、振动、网络流量以及测试者是否清醒等等。如果可以控制条件的话，就可以让错误一直发生。
如何控制条件？
查明它们，找没有初始化的数据、随机数据输入、时序误差、多线程同步和外部设备等等。在硬件中，找噪声、振动、温度、时序和部件误差等等。
一旦想到了有哪些条件可能影响系统，就要大量尝试和这些条件相符合的各种形式。初始化这些条件，然后按照已知模式把条件作为对问题软件的输入。尝试控制时序，然后改变它，看系统在某个特殊设置下是否会失败。
有时就能发现当控制某个条件时，问题消失，这就找到了导致失败的条件。发生了这种情况，就要尝试该条件下每个可能的值，直到找到导致系统失败的值。
如随机的数据输入模式间歇性导致系统失败，而固定数据模式不会导致失败，那么尝试每个可能的数据输入模式。
如果有些条件无法控制，就增加它的随机性。若故障由低概率事件引起，问题是间歇性的，可以通过增加条件随机性提高事件发生的频率，让错误更频繁地发生。它可以告诉我们失败是由什么条件引起的，让我们更容易看到失败。注意，对条件放大操作的时候，不要引起新错误。
【6）如果做了所有尝试后，问题依然间歇性发生】
制造失败的目的：
1 观察错误
要能看到失败，如果它不是每次都发生，就必须忽略不发生的时候，在每次发生时观察，在运行时捕捉相关信息，方便在发生失败后查看这些数据。
方法：让系统在运行时尽可能多地输出信息，把它们记录到调试日志文件中。
把正常运行和错误运行放一起比较，捕捉到正确信息的话，就可以看到正常与错误之间的区别。观察只在错误运行中才发生的事情！！！
失败是间歇的，这样可以识别并且捕捉发生错误的条件，然后对它分析。
2 查找线索
注意看起来和问题有关系的操作模式，但不要被表面现象误导。
失败是随机发生的，可能无法收集到足够多的统计样本来判断，但是不意味着看到的巧合和问题没有任何联系。如果没有直接影响，可能影响是简洁的，隐藏在其他随机因素后面。获得足够信息，可以确定哪些因素总是和bug有关，哪些因素总是和bug无关。找问题根源的时候，这些因素需要重点关注。
3 确认是否已经修复
失败随机发生，要证明bug是否修复就很困难。如果用统计测试的方法，运行的样本越多，结果越准确。
但更好的方法是找一个总是和失败有关系的事件序列，即使序列本身就是间歇性的，它发生时，一定会失败。
那么认为已经修复bug时，就可以运行测试，直到序列出现，若无失败，就确实已经修复了bug。
【7）“那不可能发生”】
忘掉假设，让错误再次在工程师面前发生，或尝试新的测试策略，指明问题的真正根源在哪里。
【8）永远不要丢掉调试工具】
一种测试工具可以在其他的调试场合重复使用。设计时，应该考虑到这点，并使其容易维护和升级。因此要采用好的工程技术，并且实现文档化。把它加入到源代码控制系统中，然后构建到你的系统中，以便可以随时使用。不把它当作一次性的工具来编码，扔掉它也可能是错误的。一个工具很有用，实际上可以把它当产品来卖。很多工具可能比产品还要畅销，总之工具可能非常有用，用处也难以想象。

3 不要想，而要看

“在没有事实作为参考以前妄下结论是个很大的错误。主观臆断的人总是为了套用理论而扭曲事实，而不是用理论来解释事实。” 福尔摩斯，《波希米亚丑闻》

亲眼看到底层的失败是非常重要的，猜测失败如何发生，将会让你修复一些根本不是bug的问题。这样的修复不仅不会解决问题，还会浪费时间和金钱，甚至破坏其他地方。
所有工程师都是思想家，喜欢思考，因为它有趣且胜过体力劳动，是我们成为工程师的首要原因。
虽然我们有各种各样好的设想，但是发生问题的原因更加多样化，即使是最有想象力的工程师也没法想象。
为什么我们认为能够用思考找到问题？因为我们是工程师，想比看要简单得多。
观察是很难的，需要做复杂的行为，硬件的要做实验夹探针、焊接、试探，而软件需要设置断点、添加调试语句、监视程序值和检查内存。需要大量工作。
想是一种接近，试图找出问题所在。是容易得出的结论，看起来提供了找到问题的简单方法，但事实并非如此。
【1）观察失败】
仔细观察，找到足够多的问题细节，才能调试它。如果不能留意实际情况发生的全过程，就极有可能曲解很多问题。
猜测某个地方出了问题，就修复它，但如果实际上错误发生在另一个地方呢？还有可能不仅没修复，还可能把问题隐藏，并且破坏了其他地方。
一定要亲眼看到实际错误是如何发生的。观察往往比猜测能够更快地找到问题。因为猜测虽然看起来是捷径，但是这条捷径并不会带你找到问题的根源。
【2）查看细节】
为了发现故障而观察系统，都会了解更多与失败有关的信息。这将帮你确定应该进一步观察哪些地方来获得更多细节。最后会获得足够多的细节，这时才能用这些细节来查看设计并找到问题的原因。
在停下来思考问题之前，对细节的观察要到什么程度？一直观察，直到把问题的原因锁定在几种可能性之内。
经验可以起到帮助作用，就像理解系统会起到帮助作用。作出了错误的假设，并且沿着它追查问题时，经验会告诉你在特定情况下追查到什么程度就要停止了，什么时候问题的原因已经被缩小到一个很小的范围内。
评判标准：不是多快地提出一个猜测，也不是猜测得有多好，而是尽可能少地按错误的猜测行动。
【3）问题忽隐忽现】
看到底层的失败细节后，当你认为已修复bug时，容易证明已经修复。不必依靠统计数据，可以看到错误不再发生。
【4）对系统进行插装】
若已经决定观察系统，就要采用一些观察措施。把工具植入到系统中或连接到系统上。在调试时构建特殊版本的系统，以便把工具插装到系统中，或添加外部的插装工具
a.设计插装工具
在性能监视器中输入各种有意义的变量，以便在运行时观察它们。在任何情况下，都应该开启一个调试窗口，且让代码输出状态消息。该窗口应该可以把消息保存到调试日志文件中。
收集的状态消息越多，越有利于调试，但应该有某种方式来控制选中消息或消息类型的开启和关闭，以便为了调试特定问题而重点查看所需的信息。
不过，把消息输出到调试窗口会使得系统发生改变，影响bug，太多消息影响系统处理速度。
最基本的原则是从设计一开始就考虑调试问题，把插装作为产品需求的一部分，写入功能规格和API定义中。
标准的实用工具集中必须包括调试监视器和分析过滤器，这些会为你带来额外的好处，不但使最后的调试过程变简单，还会在你思考哪里需要做插装是，有助于更好地设计系统，并且从一开始就避免某些bug。
b.过后构建插装
确保起始的设计环境和发现bug时的环境相同，再增加所需的插装工具。需要相同的软件和硬件环境。找到问题后，解决并清除所有插装，以便不影响最终产品。
调试时应该查找的信息是？选择的那部分内容应该可以证实你的判断，或显示出未意料到的行为。关键是获取有关的细节，查看函数调用和推出，以及它们的参数和返回值。获取详细信息！
c.不要害怕深入研究
如果代码有bug，为了修复它，你需要重新构建软件。构建一个调试版本，以便可以查看源代码，增加新的调试语句来查看真正需要查看的参数。
d.添加外部插装
如果不想或无法植入内部插装工具，至少要加外部插装工具。
e.日常生活中插装
比如说水压计、探针、金属探测仪等等。
【5）海森堡测不准原理】
海森堡原理：你要么测量一个粒子的位置，要么测量它向哪个位置运动，但这二者中有一个测量越精准，另一个就越测不准。
无法得到准确测量的原因是，探针成为了系统的一部分。所以说，测试工具影响了被测系统。
【6）猜测只是为了确定搜索的重点目标】
猜测是好事，当你理解了系统，猜测可能接近现实，但是只是为了确定搜索的重点。
尝试修复问题之前，依然要再次看到失败，以便确认你的猜测是正确的。
不要过分相信你的猜测，以免被误入歧途。除非按照某个特定思路猜测，是因为某些问题比其他问题更容易出现，或者比其他问题更容易修复。

4 分而治之

反复把问题分成好的一半和坏的一半，来缩小搜索范围，进一步研究有问题的一半。
【1）缩小搜索范围】
缩小搜索范围，向目标追踪，找到目标范围。逐次逼近！再某个可能范围内找到问题，从范围的一端开始，先搜前一半，看有没有错。有错再缩小
【2）插入易识别的模式】
当bug效果微小或者数据看起来完全随机，甚至很明显的错误耶无法找到明显原因时，用一个真正易于识别的输入或测试模式。
植入已知输入模式时，不要因为设置了新的条件而改变bug。若bug与模式密切相关，那么植入一个人公设置的模型可能会将问题隐藏起来。
【3）从有问题的支路开始查找问题】
从主源头开始搜索，可能会因为找错支流浪费大量时间。不要从好的一端开始确认一些正确的事情，从错误的一端开始，然后向上游追查。把分支点作为测试点，问题再上游就分别查看每个分支的小段。
【4）修复已知bug】
如果同时出现了多个问题，确实查明了其中一个问题的话，就立刻修复它，再找其他问题。如果修复了已知的错误，就专心致志找其他问题。有时修复了一个问题，另一个问题也解决了，俩问题实际上是一个bug。若修复某个问题对其他问题有影响，先修复后再测试其他问题。若修复一个问题后会出现新问题，尽早发现，有更多时间处理。
【5）先消除噪声干扰】
有些特定类型的bug可能会引起其他bug，要先找并且修复它们。比如未初始化的变量会导致很多随机行为，从而为工作带来麻烦。不要完美主义，别为了达到全面的高质量而把所有不好的设计都修复一遍，如果没有实际问题，就保留它们。

5 一次只改一个地方

【1）用步枪而不是散弹枪】
如果你真的看到了错误，就应该只修复这个地方。科学方法是为了看到一个变量的影响，尝试控制可能影响结果的所有其他变量。隔离和控制变量的方法类似于把已知数据输入到系统中，可以帮你看到奇怪的事情如何发生。
【2）双手抓住黄铜杆】
不要随便改变系统的不同部分，要克服这样的冲动，而先仔细看清楚问题出在哪里，不要快速设置新的条件！
【3）一次只改变一个测试】
一次只改变一个地方，以方便判断哪个参数有影响。如果做了改变没什么效果，就马上改回来。
【4）与正常系统进行比较】
一旦掌握了可以制造失败的方法，就有绝佳的机会成为出类拔萃的工程师。同时运行系统的一个正常的例子和有问题的例子，然后并排观察两个调试记录，注意它们之间的区别。很多差别不是又bug引起的，所以需要不断解释差别，把两者之间的差别缩小到只和bug有关，排除其他干扰。尝试从相同相机的连续测试中获得调试记录，不要用不同的机器、软件、参数和用户输入，也不要再不同的世间和不同的环境下测试。
由于不是真正知道什么与bug有关，所以要对一切可以测试的地方做测试！如果测试完了发现某个方面和bug无关，那就把它从两个调试日志中删除。
对大量无关数据做过滤，不过相同的无关数据在两个调试日志中都出现，就忽略即可。关于如何查数据的知识不适合初学者，也不是写一个程序就可以做到的。要过滤掉由时序或其他因素引起的差别，超出了初学者的水平。软件可以做到就是帮忙对日志格式化和过滤。看冗长、复杂的日志，可能只想看可疑部分，有线索，不错，没有线索就看所有的日志。
【5）从上次正常工作依赖，改变了什么】
有时正常和错误的系统之间的区别来源于一项更改，改完正常的系统就出错了。有用的方法是找到第一个让系统出错的版本，找到了再前进到下一个版本，验证故障是否再次出现。所以源设计跟踪系统十分重要，这样就可以查看所有任何版本之间的所有区别。这就是咱们的git。

6 保持审计跟踪

有时候看起来最不起眼的事情，实际上却是导致bug发生的关键。所以，记录下每一件事情，可能不起眼的事情很重要。文中的例子是视频压缩算法和测试时穿的衣服的图案复杂度有关系！
【1）记下你的每步操作、顺序和结果】
检查问题时，记下所做的事情、做事的顺序，发生的结果。
必须清楚每一个步骤和每步执行的结果，以此确定在调试时应该重点关注哪一步。
【2）魔鬼隐藏在细节中】
描述事情的时候要具体且一致，要说清楚到底是哪个系统和哪个系统之间出现了什么样的问题，只有掌握了基本的症状后，才能开始调试问题。
除了记录发生了什么事情以外，另一个需要注意的细节的问题的严重程度。需要注意噪声持续多久以及它的干扰性有多大，持续非常短可以忽略不计，持续时间长的噪音要仔细研究一下。
从现在起，开始怀疑并且注意所有的细节！
【3）关联】
将某些症状和其他症状或调试信息关联起来，非常有用。
什么情况、条件触发下，在什么时间发生的，持续时间有多长。
清晰详细准确的描述可以让人更快定位到问题所在。
很多bug都是通过把症状和人员时间表关联起来后发现的。
【4）用于设计的审计跟踪在测试中也有用】
源代码控制系统可以用来重建之前的软件版本。工程师共同开发一个项目时，这些系统可以避免各自的代码互相干扰。
它们还提供了设计的审计记录，方便知道系统在合适做了什么改变，必要的时候可以恢复到一个已知的状态。
对设计有用，对调试过程也有用。
系统的版本显示出现bug时，可以有变更记录，记下系统从上一次正常工作依赖都做了哪些改变。
如果其中的条件相同的话，就可以准确知道哪些代码引起了问题，并且从这些地方入手解决问题。
源代码控制系统不仅跟踪程序代码，还跟踪用于构建程序的工具。而工具控制对准确重建版本的用途极大。
若有一些工具变化没注意到，就会导致一些奇怪的问题。
【5）好记性不如烂笔头】
在细节方面，永远不要相信你的记忆，把它写下来。相信记忆，会制造很多麻烦。
你会忘掉你认为不重要的细节，这些细节会被证明是重要的，对后来解决另一个不同问题的人可能很重要。
你无法准确地记住事情是如何发生的、发生的顺序以及事件之间有何关系，所以把事情记下来，最好用计算机来记录。
备份，把它加到bug报告后面，这样就很容易发送给及他人，也可以用自动分析工具过滤它。
把做的事情何结果记录下来，保存调试日志何跟踪记录，注明相关的事件和影响。

7 检查插头

【1）怀疑自己的假设】
永远不要相信自己的假设，尤其是假设在一些无法解释的问题中是核心因素的时候，应该问自己一个古老、看似愚蠢的问题：插头插上了吗？
虽然问题看上去愚蠢，但是它经常发生。通常问题发生在较低的层次上。比如说有没有提供电源，有没有正确安装图像驱动，是否运行了正确的操作系统，是否启用了功能，考虑是否运动了需要的代码，比如改完了代码，有没有载入新代码。
看到了一个问题，常在某个特定位置看到了问题。系统没有正确操作的条件，所以出现了很奇怪的行为。
【2）从头开始检查】
启动条件是否正确？如果程序运行之前要初始化内存，又没有显式执行操作，情况会更糟。有时启动条件是正确的，但是向投资者展示时，却出错了。
【3）对工具测试】
开发工具不匹配可能导致一些非常奇怪的bug。不仅对工具做的假设有错误，工具本身也可能有bug。
对调试工具所做的假设也可能是错误的。是否运行了正确的编译器？量表是不是没电了？

8 获得全新观点

【1）寻求帮助】
求助的原因：获得全新观点、专业知识和经验。
人们通常很愿意帮忙，因为这给他们证明自己很聪明的机会。
①获得全新观点
人按照自己老一套的思路很难看清全局。我们都是普通人，对任何事情都有偏见，包括对bug藏在哪里的看法。偏见会导致我们没法看清实际情况。
其他人有不同的偏见，可以从新角度看问题，从而给我们带来启发，帮忙找到新方法。
向别人解释问题，也可以让人有全新的认识，然后自己就解决了问题。对事实组织的过程让人跳出原来的思维模式。
②询问专家
系统的某部分可能很神秘，可以咨询专家了解需要掌握哪些知识。不过一定要找一位真正懂你问题的专家，如果只是讲书一些晦涩难懂的时髦理论，那么他可能只是一个吹嘘技术的江湖郎中。任何情况下专家都更理解系统，因此它们知道找问题的大致路线图，也可以给搜索工作提供很好的提示。所以找到bug时，可以帮忙设计一个正确的解决方案，不会影响系统的其他部分。
③借鉴别人的经验
如果你经验不足，你周围可能有人以前见到过你遇到的情况。你向他们快速描述事情的经过后，他们会准确地告诉你出了什么问题。
专家难求，有某一特定领域经验的人可能也很难找到，所以需要高昂的费用，但这笔钱是值得的。有些系统提供了故障维修指南，那就在遇到某个部件损坏的问题，而非设计问题时，可以求助这本指南。
【2）去哪寻求帮助】
求助，有很多资源，取决于想获得深入见解还是专业知识，或者经验，或者其中几项。
有些某个主题的专家，有些公司开发知识管理系统，可以查询公司只是，并了解掌握的知识。
如果用第三方供应商的设备或软件，可以给他们发送电子邮件或打电话。
向供应商咨询，不一定是客服，反正多阅读手册。也可访问一些提供服务的供应商的信息发布到往深，可以访问网站来查看提示和样例程序。
也有资源提供更基本和通用的知识，有工具编程语言和最佳设计实践，还有调试。
【3）放下面子】
你可能害怕求助，认为这是无能的表现，其实只是说明你急于修复bug。如果获取了正确的见解、专业知识和经验，就可以更快地修复问题。这不会暴露你旦弱点，然而说明你明智地选择了帮助。当然，不要认为自己很无能，而把专家看成是神，有时专家会把事情弄错，如果你坚持认为自己是错误的，会很糟糕。
【4）报告症状，而不是理论】
报告症状，不要讲理论。要获得全新的观点，是因为你的理论不起作用。找一个人，讲理论，那么也会把他拉到原来的思维定式中。可能也把需要让他知道的关键细节隐藏起来。
你对自己有偏见。寻求帮助时，描述发生的事情，描述看到的一切。有可能把条件描述清楚，告诉别人什么事情如何间歇发生。
让他提出自己的观点，也许和你的相符或者全然不同，这就是你想要的。好多帮助者可以穿透过去理论的迷雾，找到事实，别把别人拉到你的思维定式中！
如果你是帮助者，则不要被求帮助者的理论所污染！！！
哪怕不肯定，也可提出来。对于不好判断的灰色地带，有些数据看起来很别扭，像错误的，或和问题有关系，但不确定原因。有些地方值得提出，当你发现了一些出乎意料或不理解的事情。可能与问题无关，但至少有用。

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

【1）检查问题确实已被修复】
立刻验证是否已经修正问题，不要假设，而要测试。无论看起来多么明显，都无法保证修复是有效的，直到做了测试。
【2）检查确实是修复措施解决了问题】
如果认为已经修复了设计问题，取消修复，确认系统再次失败，然后再修复，再验证问题已经修复。直到经过修复、失败、再失败到修复，才能证明已经修复了问题。
调试期间会改变不属于修复的东西，所以撤销修复看看到底会不会出问题，就能确认修复是有效的。
有些情况下，这个是不适用的。
【3）bug不会自己消失】
bug不会在不修复的情况下，自动修复。如果之前使得系统故障过，由因为某种方式改变了条件，它不再出故事。如果全是猜测，修改很多地方，也许碰巧会解决问题，但是不知道是怎么解决的。不管怎么说，都要有所作为。
【4）从根本上解决问题】
如果一个硬件识别，不是无缘无故坏掉的。要找到真正的失败之处，而不是简单更换零件。
【5）对过程修复】
你必须修复设计过程，确保在需求、设计和测试阶段正确考虑问题。

从帮助台得到的观点是不明确的

如果只能从远程方式了解问题，眼睛和耳朵接收到的信息不准确。
1 遵循规则。无论用户多么糊涂，都要找到应用规则的途径。
2 对行动和结果加以确认。用户会误解你的意思，也会犯错，确认他们说的和做的可以尽早发现这些问题。
3 用自动工具。不要让用户参与系统生成日志和远程监控与控制工具。
4 用可用的故障检修指南。要处理可能已知、好的设计，不要忽略历史。
5 帮助完善故障检修指南。找到某个已知系统的新问题，将解决问题的所有内容进行归档，从而帮助下一位支持人员。