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

一、调试九大规则

  • 理解系统

  • 制造失败

  • 不要想，而要看

  • 分而治之

  • 一次只改一个地方

  • 保持审计跟踪

  • 检查插头

  • 获得全新观点

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

二、九大规则的具体解释

理解系统

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

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

你需要做到以下：

  • 阅读手册。阅读相关文档

  • 仔细阅读每个细节

  • 掌握基础知识

  • 了解工作流程。知道所有的模块和接口都是做什么

  • 了解工具。花时间学习与工具的一切，同时要了解工具的局限性

  • 查阅细节。不应盲目相信自己的记忆，养成良好的查阅习惯

制造失败

简单来说，就是复现 bug 。

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

  • 可以观察它

  • 可以专心查找原因。准确地知道在什么条件发生，有助于集中精力查找原因

  • 可以验证是否已修复问题

    怎么制造失败（重现）：

  • 从头开始。试着从一个已知的状态出发

  • 引发失败。尽量自动化

  • 但不要模拟失败。要模拟导致失败的条件，而不是模拟识别机制本身

  • 处理间歇性失败（偶现 bug ）。改变能控制的条件，直到失败发生

  • 记录每件事。让系统尽可能多的输出信息，并记录到日志

  • 如果得到足够多的信息，需要确定哪些与 bug 有关

  • 用好调试工具

不要想，而要看

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

  • 观察失败。仅靠猜测某个地方出了问题就修复它，不仅没修复问题还可能把真正问题隐藏起来，还误以为修复了问题

  • 查看细节。一直观察，直到把问题原因锁定在几种可能之内

  • 植入插装工具。其实就是用工具调试，并记录日志

  • 不要害怕深入研究

  • 注意海森堡效应。测试工具可能影响被测系统

  • 猜测只是为了确定搜索的重点。但不要过分依赖猜测以免被引入歧途

分而治之

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

  • 确定问题范围

  • 逐步逼近缩小搜索范围

  • 从有问题的一边开始搜索。不要把精力花费在没问题的地方

  • 修复探索过程中的已知bug

  • 消除干扰因素

一次只改一个地方

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

  • 隔离关键因素，别改出了其它问题

  • 一次只改一个测试

  • 与正常情况进行比较。这样才能发现问题所在

  • 确定自从上一次正常工作以来你改变了什么

保持审计跟踪

  • 记下你所做的事、做事的顺序，以及发生的结果，写下来

  • 任何细节都可能是重要的

  • 把时间关联到一起

  • 检查代码关联工具看是否是那一次修改引入了 bug

  • 把 bug 修复过程记录下来，形成自己的 bug 修复集

检查插头

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

  • 质疑你的假设

  • 从问题开始观察

  • 对工具进行测试，工具本身也可能有 bug

获得全新观点

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

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

  • 寻求帮助。人们通常很愿意帮忙，因为这给了他们一个证明自己很聪明的机会

  • 向别人解释问题会让你对问题有全新的认识。小黄鸭调试法

  • 咨询专家，获取专业知识

  • 借鉴别人的经验。如果有人出现过类似问题，不妨找他们了解下

  • 放下面子。bug 发生了，以除掉 bug 为自豪，而不要非得已自己除掉 bug 才为自豪

  • 寻求帮助时，报告问题发生现象，而不是自己的猜测，以免误导他人

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

  • 验证问题确实已被修复。不要假设它已被修复，要测试它

  • 验证确实是你的修复措施解决了问题。而不是自己在修复过程中误操作

  • bug 从来不会自动消失。也许当时复现不了，当它终会出现

  • 从根本上解决问题

  • 对过程进行修复

三、当你的用户发现了 bug

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

  • 不能全信用户的观点

  • 多依赖日志

  • 要让发生问题的用户告诉你他们做了什么

  • 不要假设用户如何使用你的产品。对所有的事情都要进行确认

  • 如果问题再次复现了，让用户联系你