调试九法: 软硬件错误的排查之道 (David J. Agans 著)

第1章 简介 (已看)

第2章 总体规则 (已看)

第3章 理解系统 (已看)

第4章 制造失败

第5章 不要想, 而要看

第6章 分而治之

第7章 一次只改一个地方

第8章 保持审计跟踪

第9章 检查插头

第10章 获得全新观点

第11章 如果你不修复bug, 它将依然存在

第12章 通过一个案例讲述所有规则

第13章 牛刀小试

第14章 从帮助台得到的观点

第15章 结束语 (已看)

第1章 简介

"你知道, 现阶段我非常忙, 但我打算在晚年倾力写一本书, 把所有侦探艺术都集中写到这本书里."　　----福尔摩斯, 《格兰其庄园》

　　1.1 本书如何教会你调试

根据我26年的系统设计和调试经验,我发现了两件重要的事情

1. 如果查找一个bug花费了大量时间, 那么原因可能是忽略了某个最基本的, 最重要的规则, 一旦应用了那条规则, 很快就会找到问题
2. 擅于快速调试的人已经深刻理解并应用了这些规则,而那些很难理解或使用这些规则的人则很难找到bug

　　1.2 这些规则都很显而易见

当你读到这些规则时, 你可能会自言自语地说: "这些都是一些明显的规则啊."不要着急下结论, 这些规则确实都很明显(而且常常是基本的规则),但如何把它们应用于特定的问题就不总是那么显而易见了. 而且不要把"显然"和"容易"混淆在一起,这些规则遵守起来并不总是那么容易, 因此在解决实际问题时常常被忽略

关键是记住并应用这些规则.

　　1.3 本书适用于任何人

　　1.4 本书可用于调试各种问题

　　1.5 本书的主旨不在预防, 保证或筛选

　　1.6 调试不仅仅是故障检修

虽然调试和故障检修(troubleshooting)这两个词常常混用, 但它们实际上还是有区别的, 而且本书作为一本调试书,与其他数以百计的故障检修指南也是存在区别的. 调试通常是查明为什么一个设计没有按计划工作, 而故障检修通常是在已知设计没有问题的情况下, 查明一件产品出了什么问题----可能是某个文件被删除了, 某条线断了或者是某个元件出了问题.

　　1.7 有关案例故事

　　1.8 精彩内容, 即将上演

第2章 总体规则

"我在这里要讲的理论(可能你认为它们非常荒谬),实际上都是非常实用的,我就是靠着它们挣得我这份面包和奶酪的" 　　----福尔摩斯, 《血字的研究》

第3章 理解系统

"人们要想掌握本书中所有有用知识也并非完全不可能, 事实上我就是尽全力这样做的."　　----福尔摩斯, 《杀人的五个橘核》

　　3.1 阅读手册

理解系统的基本方法就是阅读手册.

　　3.2 逐字逐句阅读整个手册

人们在调试的时候,通常都不会彻底阅读系统手册. 它们采取跳读的方式, 查看他们认为重要的一些章节, 但问题的线索可能就隐藏在被略过的那些章节中.

　　3.3 知道什么是正常的

当你检查系统时, 必须知道系统的正常工作状态

你必须掌握一些你所工作的技术领域的基础知识

缺乏基础知识解释了为什么很多人找不到自己家用电脑的毛病: 他们只是没有理解计算机的基本原理

　　3.4 知道工作流程

当你尝试寻找bug时, 必须知道要查找的路线, 开始时, 你需要猜测在哪里把系统分隔开, 以便隔离问题, 这种猜测完全取决于你对系统功能划分的了解. 你至少要大体上知道所有的模块和接口都是做什么的.

　　3.5 了解你的工具

调试工具是用来观察系统的眼和耳, 你必须选择正确的工具, 正确地使用工具, 并正确地解释得到的结果

　　3.6 查阅手册

　　3.7 小结

理解系统

这是第一条规则, 因为它是最重要的

• 阅读手册　　　　　　它会告诉你在使用除草机时, 要在除草头上涂润滑油, 这样除草绳就不会被烧化
• 仔细阅读每个细节　　有关微处理器如何处理中断的详细信息就隐藏在数据手册第37页
• 掌握基础知识　　　　电锯本来就会发出很大的噪声
• 了解工作流程　　　　引擎的转速可能与轮胎的转速不同, 这时由传动轴造成的
• 了解工具　　　　　　弄清楚体温计的哪一端才是用来测量体温的, 弄清楚 Glitch-O-Matic 逻辑分析器的强大功能是如何使用的
• 查阅细节　　　　　　连爱因斯坦都会去查阅细节, 而Kneejerk却盲目相信自己的记忆力

第4章 制造失败

"什么也比不上直接取得的证据来得重要"　　----福尔摩斯, 《血字的研究》

关键是在发生失败的时候要看到它. 这是很多调试的典型问题----你看不到问题是如何发生的,因为你方便观察的时候, 它并没有发生. 这并不是说它只发生在深夜(即使你最终是在深夜时发现了它),它可能是每7次中只发生1次, 或者是Charlie测试它的时候, 碰巧发生了一次

如果Charlie现在正在我的公司工作, 你问他: "当你发现一个故障时该怎么办?" 他会回答说: "试着让它再次发生". 这样做有3个原因

• 可以观察它.　　　　　　　　　　要观察错误, 就必须使它发生. 我们必须尽可能有规律地制造失败
• 可以专心查找原因　　　　　　　 准确地知道问题再什么条件下会发生, 有助于集中精力查找原因　
• 可以判断是否已修复问题　　　　当你认为已经修复了问题时, 如何才能确信它确实已被修复呢?那就是明确知道问题是如何发生的. 当问题没有修复时, 如果你执行X操作, 失败率为100%; 在修复问题后, 再执行X操作, 如果失败率为0, 那么你知道bug确实已被修复

　　4.1 制造失败

仔细观察你做了什么, 然后再做一次, 并且记下你做的每个步骤. 然后, 按照你自己所写的步骤去做, 确定这样做确实导致了错误.

　　4.2 从头开始

　　4.3 引发失败

　　4.4 不要模拟失败

　　4.5 如何处理间歇性 bug

　　4.6 如果做了所有尝试之后问题仍然间歇性发生

　　　　4.6.1 仔细观察失败

　　　　4.6.2 不要盲目相信统计数据

　　　　4.6.3 是已修复bug, 还是仅仅由于运气好, 它不再发生了

　　4.7 "那不可能发生"

　　4.8 永远不要丢掉调试工具

　　4.9 小结

制造失败

虽然看起来很简单, 但如果不制造失败的话, 调试就会变得很困难

• 制造失败
• 从头开始
• 引发失败
• 但不要模拟失败
• 查找不受你控制的条件
• 记录每件事情
• 不要过于相信统计数据
• 要认识到"那"是可能会发生的
• 永远不要丢掉一个调试工具

第5章 不要想, 而要看

　　5.1 观察失败

　　5.2 查看细节

　　5.3 问题忽隐忽现

　　5.4 对系统进行插装

　　　　5.4.1 设计插装工具

　　　　5.4.2 过后构建插装

　　　　5.4.3 不要害怕深入研究

　　　　5.4.4 添加外部插装

　　　　5.4.5 日常生活中的插装

　　5.5 海森堡测不准原理

　　5.6 猜测只是为了确定搜索的重点目标

　　5.7 小结

第6章 分而治之

　　6.1 缩小搜索范围

　　　　6.1.1 确定范围

　　　　6.1.2 你在哪一侧

　　6.2 插入易于识别的模式

　　6.3 从有问题的支路开始查找问题

　　6.4 修复已知bug

　　6.5 首先消除噪声干扰

　　6.6 小结

第7章 一次只改一个地方

　　7.1 使用步枪, 而不要用散弹枪

　　7.2 用双手抓住黄铜杆

　　7.3 一次只改变一个测试

　　7.4 与正常系统进行比较

　　7.5 自从上一次能够正常工作以来你更改了什么

　　7.6 小结

第8章 保持审计跟踪

　　8.1 记下你的每步操作 顺序和结果

　　8.2 魔鬼隐藏在细节中

　　8.3 关联

　　8.4 用于设计的审计跟踪在测试中也非常有用

　　8.5 好记性不如烂笔头

　　8.6 小结

第9章 检查插头

　　9.1 怀疑自己的假设

　　9.2 从头开始检查

　　9.3 对工具进行测试

　　9.4 小结

第10章 获得全新观点

　　10.1 寻求帮助

　　　　10.1.1 获得全新观点

　　　　10.1.2 询问专家

　　　　10.1.3 借鉴别人的经验

　　10.2 到哪里寻求帮助

　　10.3 放下面子

　　10.4 报告症状, 而不是理论

　　10.5 小结

第11章 如果你不修复bug, 它将依然存在

　　11.1 检查问题确实已被修复

　　11.2 检查确实是修复措施解决了问题

　　11.3 bug从来不会自己消失

　　11.4 从根本上解决问题

　　11.5 对过程进行修复

　　11.6 小结

第12章 通过一个案例讲述所有规则

第13章 牛刀小试

　　13.1 灯和吸尘器的故事

　　13.2 大量出现的bug

　　13.3 宽松的限制

　　13.4 识破bug

第14章 从帮助台得到的观点

　　14.1 帮助台的限制

　　14.2 规则, 帮助台风格

　　　　14.2.1 理解系统

　　　　14.2.2 制造失败

　　　　14.2.3 不要想, 而要看

　　　　14.2.4 分而治之

　　　　14.2.5 一次只改一个地方

　　　　14.2.6 保持审计跟踪

　　　　14.2.7 检查插头

　　　　14.2.8 获得全新观点

　　　　14.2.9 如果你不修复bug, 它将依然存在

　　14.3 小结

第15章 结束语

　　15.1 调试规则网站

　　15.2 如果你是一名工程师

　　15.3 如果你是一名经理

　　15.4 如果你是一名教师

　　15.5 小结

"黄金"规则意味着以下几条特点

• 通用　　　　你可以将它们应用于任何系统上的任意调试场景
• 基础　　　　它们为适用于你的系统的特定工具与技术提供了框架, 并对这些工具和技术的选择起到指导作用
• 至关重要　　如果不遵循所有这些规则, 就无法有效地进行调试
• 容易记忆