程序调试界的独孤九剑-《调试九法》读书笔记

偶然得知有本关于程序调试方法论的书调试九法，顺手一番，确实还不错。遇到疑难问题时对照着看看方法论，对解决问题会有奇效。

一、调试九大规则

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

二、九大规则的具体解释

理解系统

简单来说，就是要熟悉业务。这条规则最重要。

更具体点，你必须知道系统的工作原理以及它是如何设计的，某些情况下，还要知道为什么这样设计。

你需要做到以下：

• 阅读手册。阅读相关文档
• 仔细阅读每个细节
• 掌握基础知识
• 了解工作流程。知道所有的模块和接口都是做什么
• 了解工具。花时间学习与工具的一切，同时要了解工具的局限性
• 查阅细节。不应盲目相信自己的记忆，养成良好的查阅习惯

制造失败

简单来说，就是复现 bug 。

试着让 bug 重现有一下3个原因：

• 可以观察它
• 可以专心查找原因。准确地知道在什么条件发生，有助于集中精力查找原因
• 可以验证是否已修复问题

怎么制造失败（重现）：

• 从头开始。试着从一个已知的状态出发
• 引发失败。尽量自动化
• 但不要模拟失败。要模拟导致失败的条件，而不是模拟识别机制本身
• 处理间歇性失败（偶现 bug ）。改变能控制的条件，直到失败发生
• 记录每件事。让系统尽可能多的输出信息，并记录到日志
• 如果得到足够多的信息，需要确定哪些与 bug 有关
• 用好调试工具

不要想，而要看

凭空想象，问题可能有几千条原因，而实际的原因只有去看了才能发现。

• 观察失败。仅靠猜测某个地方出了问题就修复它，不仅没修复问题还可能把真正问题隐藏起来，还误以为修复了问题
• 查看细节。一直观察，直到把问题原因锁定在几种可能之内
• 植入插装工具。其实就是用工具调试，并记录日志
• 不要害怕深入研究
• 注意海森堡效应。测试工具可能影响被测系统
• 猜测只是为了确定搜索的重点。但不要过分依赖猜测以免被引入歧途

分而治之

其实就是排除法，逐步逼近，这是调试的核心

• 确定问题范围
• 逐步逼近缩小搜索范围
• 从有问题的一边开始搜索。不要把精力花费在没问题的地方
• 修复探索过程中的已知bug
• 消除干扰因素

一次只改一个地方

不要乱改，为验证问题，一次只改一个地方

• 隔离关键因素，别改出了其它问题
• 一次只改一个测试
• 与正常情况进行比较。这样才能发现问题所在
• 确定自从上一次正常工作以来你改变了什么

保持审计跟踪

• 记下你所做的事、做事的顺序，以及发生的结果，写下来
• 任何细节都可能是重要的
• 把时间关联到一起
• 检查代码关联工具看是否是那一次修改引入了 bug
• 把 bug 修复过程记录下来，形成自己的 bug 修复集

检查插头

一些显而易见的假设往往是错误的。

• 质疑你的假设
• 从问题开始观察
• 对工具进行测试，工具本身也可能有 bug

获得全新观点

要想重新理清一个案子的头绪，最好的方法就是把它讲给别人听。 - 福尔摩斯

如果问题没有头绪，不妨休息下，听听别人的看法

• 寻求帮助。人们通常很愿意帮忙，因为这给了他们一个证明自己很聪明的机会
• 向别人解释问题会让你对问题有全新的认识。小黄鸭调试法
• 咨询专家，获取专业知识
• 借鉴别人的经验。如果有人出现过类似问题，不妨找他们了解下
• 放下面子。bug 发生了，以除掉 bug 为自豪，而不要非得已自己除掉 bug 才为自豪
• 寻求帮助时，报告问题发生现象，而不是自己的猜测，以免误导他人

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

• 验证问题确实已被修复。不要假设它已被修复，要测试它
• 验证确实是你的修复措施解决了问题。而不是自己在修复过程中误操作
• bug 从来不会自动消失。也许当时复现不了，当它终会出现
• 从根本上解决问题
• 对过程进行修复

三、当你的用户发现了 bug

实际上很多时候 bug 是通过用户发现的，他不一定了解这些专业知识

• 不能全信用户的观点
• 多依赖日志
• 要让发生问题的用户告诉你他们做了什么
• 不要假设用户如何使用你的产品。对所有的事情都要进行确认
• 如果问题再次复现了，让用户联系你