作者阿甘斯（Agans,D.J）是一位经验丰富的工程师。根据他多年的系统设计和调试经验，他发现了两条重要的事情：
（1）如果查找一个bug花费了大量的时间，那么原因可能是忽略了某个最基本的、最重要的规则，一旦应用了那条规则，很快就会找到问题。
（2）擅于快速调试的人已经深刻理解了这些规则，而那些很难理解或使用这些规则的人则很难找到bug。
规则很简单，一共九条，多数人看了可能会案子嘀咕“不是一些显而易见的规则吗？”，但是知易行难，理解并应用才是最重要的。
并且这些规则通用性极强，不仅仅适用于工程师，因为这些基础规则是用来提供查找问题的全新方法，并让你快速找到核心问题。
下面是这九条规则：
<1>理解系统
<2>制造失败
<3>不要想，而要看
<4>分而治之
<5>一次只改一个地方
<6>保持审计追踪
<7>检查插头
<8>获得全新观点
<9>如果你不修复bug，它将永远存在
九条规则
<1>理解系统
这是最重要的一条规则，所以放在第一条。你必须理解系统的工作原理及它是如何设计的。在某些情况下还得知道为什么这样设计。如果你没有理解系统的某个部分，那么这通常是出问题的地方。
理解系统最基本的办法就是阅读手册。产品说明书、官方的技术支持文档等，都归属于手册这一含义。仔细阅读手册，解决问题的关键隐藏在细节中，遇到问题不要盲目地相信你的记忆能力，该翻手册时就要翻。通过阅读手册掌握基础的知识，了解工作的流程，这样就能迅速定位错误是由哪个步骤造成的。
所以，夯实基础十分重要。
<2>制造失败
重现错误是为了观察它发生的条件，找到原因，并且检查是否修复了这个错误。你观察时必须足够细致，记录你的步骤。查找那些不受你控制的条件（导致间歇性的失败），例如未初始化的数据，随机数据输入，多线程同步和外部设备。不要过于相信表面的统计数据，被切断腿的小昆虫遭遇突响的声音却不逃跑不是因为听觉器官在腿上！你要正确地切入要点，不被表面现象所迷惑。当你决绝了一个问题，记住这次经历，将你解决问题的工具保留下来，保不准下次就得用上。
<3>不要想，而要看
亲眼查看失败，留意实际情况发生的过程，不要想当然的凭想象猜测。通过观察，让你能尽量缩小范围至几种可能性之内。你可以利用工具去观察错误，但必须知道，工具也会影响要测试的对象。
<4>分而治之
这是调试的核心。类似于二分查找法，根据错误特征反复将问题分成好的一般与坏的一半，来缩小搜索范围，进一步研究有问题的一半。当错误的特征不明显时，可以尝试放大这个特征。查找问题时从有问题的分支上溯查找。bug之间相互保护，相互隐藏，所以出现多个bug时，修复已知的bug，解决一个，往往连带着解决了多个。
<5>一次只改一个地方
改动后不能解决问题要还原后再进行下一次改动，因为改动了后，环境条件也会发生改变，会影响错误的查找。每次改动专注于一处地方。你要能明白正常情况下的结果，与你遇见的情况做对比。在改动时，要隔离关键因素以确保每次改动只改变了一个。
<6>保持审计追踪
记录步骤（bug隐藏在细节中），要将调试的信息关联起来。运用工具记录步骤，好记心不如烂笔头。
<7>检查插头
不要忽略基础性问题的可能性，设备突然不能工作了，有可能是你的脚不小心将插头踢松了。当你用工具来测试时，确保你的工具没问题，用坏的气筒打气，问题并不出在轮胎上。
<8>获得全新的观点
放下无谓的自尊向他人，最好是专家求助，他会给你带来新的观点。在咨询时，报告问题的症状而不是你认为的原因（理论），这会将他人陷入你的固定思维中。学会利用工具搜索问题，比如Google。向小黄鸭倾诉你的想法，以理清你的思路。
<9>如果你不修复bug，他将依然存在
发现问题并采取措施后检查问题确实被修复了，且是由修复措施解决的。间歇性的bug如果不修复会一直存在。
授人以鱼不如授人以渔，作者没有讲述遇见某个具体的问题，你要怎么怎么，他通过九个规则让你学会找到问题，问题解决方式往往简单，男的是如何去找到这个问题。
网友评论