本文主要是介绍程序调试的独孤九剑，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
本文是调试九法的读书笔记，方便解不出 Bug时参考。
一、调试九大规则
理解它们并贴在你的电脑旁边
- 理解系统
- 制造失败
- 不要想，而要看
- 分而治之
- 一次只改一个地方
- 保持审计跟踪
- 检查插头
- 获得全新观点
- 如果你不修复 bug ，它将依然存在
二、九大规则的具体解释
理解系统
简单来说，就是要熟悉业务。这条规则最重要。
更具体点，你必须知道系统的工作原理以及它是如何设计的，某些情况下，还要知道为什么这样设计。
你需要做到以下：
- 阅读手册。阅读相关文档
- 仔细阅读每个细节
- 掌握基础知识
- 了解工作流程。知道所有的模块和接口都是做什么
- 了解工具。花时间学习与工具的一切，同时要了解工具的局限性
- 查阅细节。不应盲目相信自己的记忆，养成良好的查阅习惯
制造失败
简单来说，就是复现 bug 。
试着让 bug 重现有一下3个原因：
- 可以观察它
- 可以专心查找原因。准确地知道在什么条件发生，有助于集中精力查找原因
- 可以验证是否已修复问题
怎么制造失败（重现）：
- 从头开始。试着从一个已知的状态出发
- 引发失败。尽量自动化
- 但不要模拟失败。要模拟导致失败的条件，而不是模拟识别机制本身
- 处理间歇性失败（偶现 bug ）。改变能控制的条件，直到失败发生
- 记录每件事。让系统尽可能多的输出信息，并记录到日志
- 如果得到足够多的信息，需要确定哪些与 bug 有关
- 用好调试工具
不要想，而要看
凭空想象，问题可能有几千条原因，而实际的原因只有去看了才能发现。
- 观察失败。仅靠猜测某个地方出了问题就修复它，不仅没修复问题还可能把真正问题隐藏起来，还误以为修复了问题
- 查看细节。一直观察，直到把问题原因锁定在几种可能之内
- 植入插装工具。其实就是用工具调试，并记录日志
- 不要害怕深入研究
- 注意海森堡效应。测试工具可能影响被测系统
- 猜测只是为了确定搜索的重点。但不要过分依赖猜测以免被引入歧途
分而治之
其实就是排除法，逐步逼近，这是调试的核心
- 确定问题范围
- 逐步逼近缩小搜索范围
- 从有问题的一边开始搜索。不要把精力花费在没问题的地方
- 修复探索过程中的已知bug
- 消除干扰因素
一次只改一个地方
不要乱改，为验证问题，一次只改一个地方
- 隔离关键因素，别改出了其它问题
- 一次只改一个测试
- 与正常情况进行比较。这样才能发现问题所在
- 确定自从上一次正常工作以来你改变了什么
保持审计跟踪
- 记下你所做的事、做事的顺序，以及发生的结果，写下来
- 任何细节都可能是重要的
- 把时间关联到一起
- 检查代码关联工具看是否是那一次修改引入了 bug
- 把 bug 修复过程记录下来，形成自己的 bug 修复集
检查插头
一些显而易见的假设往往是错误的。
- 质疑你的假设
- 从问题开始观察
- 对工具进行测试，工具本身也可能有 bug
获得全新观点
要想重新理清一个案子的头绪，最好的方法就是把它讲给别人听。 - 福尔摩斯
如果问题没有头绪，不妨休息下，听听别人的看法
- 寻求帮助。人们通常很愿意帮忙，因为这给了他们一个证明自己很聪明的机会
- 向别人解释问题会让你对问题有全新的认识。小黄鸭调试法
- 咨询专家，获取专业知识
- 借鉴别人的经验。如果有人出现过类似问题，不妨找他们了解下
- 放下面子。bug 发生了，以除掉 bug 为自豪，而不要非得已自己除掉 bug 才为自豪
- 寻求帮助时，报告问题发生现象，而不是自己的猜测，以免误导他人
如果你不修复 bug，它将依然存在
- 验证问题确实已被修复。不要假设它已被修复，要测试它
- 验证确实是你的修复措施解决了问题。而不是自己在修复过程中误操作
- bug 从来不会自动消失。也许当时复现不了，当它终会出现
- 从根本上解决问题
- 对过程进行修复
三、当你的用户发现了 bug
实际上很多时候 bug 是通过用户发现的，他不一定了解这些专业知识
- 不能全信用户的观点
- 多依赖日志
- 要让发生问题的用户告诉你他们做了什么
- 不要假设用户如何使用你的产品。对所有的事情都要进行确认
- 如果问题再次复现了，让用户联系你
这篇关于程序调试的独孤九剑的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
