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