概要
本文主要摘录了该书的每章总结部分，这本书主要讲解了调试相关的核心理念和实践。强烈建议阅读。
理解系统
这是第一条规则，因为它是最重要的。
- 阅读手册。它会告诉你在使用除草机时，要在除草头上涂润滑油，这样除草绳就不会被烧化。
- 仔细阅读每个细节。有关微处理器如何处理中断的详细信息就隐藏在数据手册的第37页。
- 掌握基础知识。电锯本来就会发出很大的噪声。
- 了解工作流程。引擎的转速可能与轮胎的转速不同，这是由传动轴造成的。
- 了解工具。弄清楚体温计的哪一端才是用来测最体温的，弄清楚Glitch-O-Matic逻辑 分析器的强大功能是如何使用的。
- 查阅细节。连爱因斯坦都会去查阅细节，而Kneejerk却盲目相信自己的记忆力。
制造失败——观察错误、查找线索、确认是否修复。
虽然看起来很简单，但如果不制造失败的话，调试就会变得很困难。
- 制造失败。目的是为了观察它，找到原因，并检查是否已修复。
- 从头开始。修车工需要知道汽车车窗在被冻结之前你洗过车。
- 引发失败。用喷水管向漏雨的那扇窗子喷水。
- 但不要模拟失败。用喷水管向漏雨的那扇窗子喷水,而不要向另一扇不同的、“类似的”窗子喷水。
- 查找不受你控制的条件（正是它导致了间歇性失败）。改变能够改变的每件事情，振动、摇晃、扭曲，直到再现失败。
- 记录每件事情，并找到间歇性bug的特征。我们的绑定系统总是只在呼叫顺序错乱时才会失败。
- 不要过于相信统计数据。绑定问题看起来与时间段有关，但实际上真正的原因是当地的年轻人占用了电话线路。
- 要认识到“那”是可能会发生的。甚至冰淇淋的口味也会影响汽车的发动。
- 永远不要丢掉一个调试工具。自动击球板可能在某一天就会派上用场。
不要想，而要看
凭空想象，问题可能有几千条原因。而实际的原因只有去看了才能发现。
- 观察失败。高级工程师看到r真实的问题，并且能够找到原因。而初级工程师们认为他们知道错误发生在哪里，结果他们修复的地方根本没有出错。
- 查看细节。听到水泵似乎发出声音时不要停下来。到地下室查明是哪个水泵。
- 植入插装工具。使用源代玛调试器、调试日志、状态消息、信号灯和臭鸡蛋的气味。
- 添加外部插装工具。使用分析器、示波器、量表、金属检测仪、心电图仪和肥皂泡。
- 不要害怕深入研究。虽然它是软件成品，但它出问题,你必须打开并修复它。
- 注意海森堡效应。不要让仪器影响了系统。
- 猜测只是为了确定搜索的重点。大胆地猜测内存时序发生了错误，但在修复之前应该先查看它。
分而治之
当bug的藏身之地不断被缩小一半时，它将很难再隐藏下去。
- 通过逐次逼近缩小搜索范围。猜测1~ 10。内的一个数字，只需7次。
- 确定范围。如果数字是135而你却认为它在1~ 100内，那么你必须扩大范围。
- 确定你位于bug的哪一侧。如果你所在的位置有排放物，则排放管就在上游。如果没有排放物，贝”排放管就在下游。
- 使用易于查看的测试模式。从干净、清澈的水开始，以便当排放物进入河流中时很容易看到它。
- 从有问题的一端开始搜索。如果你验证的是正确的部分，那么需要验旺的地方太多了。应该从有问题的地方开始，然后向后追查原因。
- 修复已知bug。bug互相保护，互相隐藏。因此一旦找到，立即修复它们。
- 首先消除噪声干扰。注意那些导致系统问题的干扰因素。但对一些无足轻重的问题不要过于极端，也不要为了追求完美而去修改所有地方。
天才就是无止境吃苦耐劳的本领。
一次只改一个地方
我们在生活中要有一点先见之明。如果你所做的更改没有起到预期的作用，那么就把它改回来。它们可能会产生无法预料的影响。
- 隔离关疑因素。如果你在检查日照时间的影响，就不要改变灌溉方案。
- 用双手抓住黄铜杆。如果你在不知道具体发生了什么问题的情况下就试图去修理核潜艇，可能会引发一次水下的切尔诺贝利爆炸气
- 一次只改一个测试。我之所以知道我的VGA采集相位被破坏了，就是因为其他东西都没有发生改变。
- 与正常情况进行比较。如果所有出错的情况都有一些特征，而这些特征是正常情况所没有的，那么你就找到了问题所在。
- 确定自从上一次正常工作以来你改变了什么地方。我的工友改变了唱机转盘上的唱头，因此这是一个很好的调试起点。
保持审计跟踪
不要只是在心里记住“保持审计跟踪”这条规则，而要把它写下来。
- 把你的操作，操作的顺序和结果全部记录下来。你上一次喝咖啡是什么时候？你的头痛是从什么时候开始的？
- 要知道，任何细节都可能是重要的。视频压缩芯片的崩潢是由于格子衬衫造成的。
- 把事件关联到一起。“它发出噪声，从21:04:53开始，持续4秒”比仅仅说“它发出噪声”要好得多。
- 用于设计的审计跟踪在测试中也非常有用。软件配置控制工具可以告诉你哪次修订引入了 bug。
- 把事情记录下来！无论那个时刻多么恐怖，都要把它记到备忘录中，这样你才不会忘记。
检查插头
一些显而易见的假设往往是错误的。请恕我赘述，假设错误通常是最容易修复的错误。
- 置疑你的假设。是否运行了正确的代码？是不是燃气用完了？插头是否已插好？
- 从头开始。是否正确地对内存进行了初始化？是否按了除草机上的“primer bulb”按 钮？开关是否已打开？
- 对工具进行测试。是否运行了正确的编译器？燃料油表是否被粘住了？量表是不是没电了？
向别人请求帮助的三个原因:获得全新观点、专业知识和经验。在向别人描述问题的时候，一定要记住一件事:报告症状，而要讲你的理论。
获得全新观点
不管怎样，你都需要休息一下，喝杯咖啡。
- 征求别人的意见。甚至一个不说话的人体模特也能帮助你认识到你先前没有注意到的事情。
- 获取专业知识。只有VGA视频采集卡的厂商才能够肯定相位功能发生了错误。
- 听取别人的经验。别人会告诉你车内顶灯的线被挤压出来了。
- 帮助无处不在。同事、供应商、网络，还有书店，都在等待着为你提供帮助。
- 放下面子。bug发生了。以除掉bug为自豪，而不要非得以自己除掉bug才为自豪。
- 报告症状，而不要讲你的理论。不要把别人拖进你的思维定式中。
- 你提出的问题不必十分肯定。甚至连“穿了格子衬衫”这样的事情也可以提出来。
如果你不修复bug,它将依然存在
现在你已经掌握了所有的技术，没有理由再让bug存在了。
- 查证问题确实已被修复。不要假设是电路的问题，而仍然让汽车带着脏的滤油嘴路。
- 查证确实是你的修复措施解决了问题。口中大喊“Wubba!”并不是使计算机打开的窍门。
- 要知道，bug从来不会自己消失。使用最初导致它失败的方法再次制造失败。如果必须交付产品，那么就在产品中设计一个用于捕捉bug的“陷阱”，以便产品在客户现场发生失败时，把它捉住。
- 从根本上解决问题。在烧坏另一台变压器之前，先把无用的8音轨磁带卡座扔掉。
- 对过程进行修复。不要只是擦掉地上的油，而要纠正设计机器的方式。
从帮助台得到的观点是不明确的
只能通过远程方式了解向题，眼睛和耳朵接收到的信息并不十分准确，而且关键是时间紧迫。
- 遵循规则。无论用户多么糊涂，都必须找到应用规则的途径。
- 对行动和结果加以确认。用户会误解你的意思，同时会犯错误。通过确认他们所说和所做的一切可以及早发现这些问题。
- 使用自动工具。不要让用户参与系统生成的日志和远程监控与控制工具。
- 即使是最简单的假设也需要确认。是的，有些人就是不知道有电才能使用字处理器。
- 使用可用的故障检修指南。要处理的很可能就是已知的、好的设计。不要忽略历史。
- 帮助完善故障检修指南。如果找到了某个已知系统的一个新问题，将解决问题的所有内容进行归档可以帮助下一位支持人员。