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

2017-03-19

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

一、调试九大规则

  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 是通过用户发现的,他不一定了解这些专业知识

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