跳转至

1. 山重水复疑无路

有效的调试步骤：

  • 弄清楚为什么运行异常
  • 修复问题
  • 避免破坏其他部分
  • 保持或者提高代码总体质量（可读性，架构，测试覆盖，性能等）
  • 确保同样问题不要再次发生

实证方法：构建实验，观察结果

核心调试过程：

  • 问题重现
  • 问题诊断
  • 缺陷修复
  • 反思，吸取教训

澄清问题：

  • 发生了什么，应该发生什么
  • 一次一个问题
  • 先检查简单的事情

2 重现问题

2.1 重现第一，提问第二

如何重现：

  • 明确开始要做的事情（比如缺陷报告的步骤）
  • 抓住重点

控制因素：

  • 软件本身
  • 运行环境
  • 提供的输入

2.2 控制软件

2.3 控制环境

可能包含所有环境

2.4 控制输入

推测可能输入:

  • 回溯工作
  • 探测可能输入值
  • 边界分析
  • 分之覆盖
  • 利用错误条件
  • 引入随机性：模糊测试；生成模糊器；变异模糊器
  • 记录输入值
  • 日志框架。可以开启 or 关闭；日志级别；上下文（代码行数等）；分析工具（ELK）
  • 外部日志。代理服务器等
  • 负载和压力。有些缺陷只有在某种压力才表现出来（高负载网络流量，有限的可用内存）

2.5 改进问题重现

2.5.1 最小化反馈周期。编辑-执行-重新问题时间最短
  • 尽可能简单，通过二分法快速定位
  • 自动化最小输入
  • 最大限度减少所需时间，比如营造资源耗尽的局面。
2.5.2 不确定缺陷变为确定

软件之美在于确定性，但是不确定性从哪里来？

  • 开始于不可预知的初始状态。从未经初始化的内存读取数据(强制初始化，或者内存完整性检测软件)
  • 与外部系统交互: 精确控制从外部系统接收了什么
  • 故意使用随机性: 伪随机数
  • 多线程: 通过 sleep 等增加出现竞争的可能性
2.5.3 自动化
  • 自动化测试
  • 重放日志

2.6 无法重现怎么办

  • 缺陷真的存在么？
  • 在相同区域解决不同问题
  • 让其他人参与其中。不同人的视角
  • 充分利用用户群体
  • 推测法：逻辑推理，想象出错的可能性

3 诊断

3.1 不要急于动手，试试科学方法

  • 调试方法：
  • 根据你对软件运行情况的理解，提出一个可以导致这种情况的假设
  • 设计一个实验，证明假设是否正确
  • 如果无法证明你的假设，重新设计然后再次实验

  • 如果实验支持你的假设，继续证明，知道能够证明或者证伪

  • 实验必须起到验证的作用。(与他人争辩试图推翻你的假设)

  • 每次只做一个修改。多处修改可能导致错误的结论。

  • 记录你做的调试。定期回顾你已经尝试过的实验和学到的东西，使用日记簿或者电子笔记。

  • 不要忽略任何细节。凡是你不明白的都是潜在的缺陷。(Anything that you don’t understand is potentially a bug)

  • 写出假设。曾经做过的假设写到纸上
  • 可以跟踪详细信息
  • 确保不会忘记需要做的事情
  • 短暂休息，可以尝试头脑风暴

3.2 相关策略

3.2.1 插桩

使用日志，但是不要引入额外的副作用影响了原始代码逻辑。增加日志的时候，不要同时修改代码逻辑。

3.2.2 分而治之

二分法，排除一部分模块或者代码的问题。

3.2.3 源码控制工具

git 找出历史提交，分析引入缺陷的提交

3.2.4 聚焦差异

找到特殊用例，缺陷的边界

3.2.5 向他人学习

网络搜索，同事求助

3.2.6 奥卡姆剃刀

其他条件相同情况下，最简单的解释是最好的。

3.3 调试器

代码检查，断点，单步调试，检查运行状态

  • 开发初期调试器非常有用
  • 让代码以特定方式运行
  • 探究看不懂的代码

随着经验增加和TDD 思想出现，调试器使用会变少

3.4 陷阱

  • 你做的修改是正确的么？如果没有，说明你没修改到点子上。尝试引入明显的失败比如断言让其暴露出来
  • 验证假设。思维定势造成的先验假设可能会让你得不到结果
  • 多重原因。问题有时候是复杂的，
  • 对问题进行隔离，找到一个方法重现缺陷。
  • 先找同一个区域内其他较明显的缺陷，扫清障碍，让缺陷更加明显
  • 查出变化并且控制它。第三方系统或者数据库。

3.5 思维游戏

  • 旁观调试法（小黄鸭）。求助其他人。倾听；提问；留意没有探究过的地方；了解接下来将会发生什么。解释问题会帮你理清思路
  • 角色扮演
  • 换换脑筋。潜意识帮助你
  • 做些改变，什么改变都行。出去散个步最好
  • 福尔摩斯原则：当你排除了一切不可能之后，无论它多么不可思议，它也一定是真相

3.6 验证诊断

  • 向其他人解释你的诊断
  • 检查源代码原始副本
  • 多和其他人讨论，并假设你是错的

4 修复缺陷

4.1 清楚障碍

从一个干净的代码树开始修改。

4.2 测试

  • 保证现有测试都可以通过
  • 添加一个或者多个新的测试程序
  • 修复 bug
  • 证明修复起了作用
  • 证明回归测试没有失败

4.3 修复原因而非修复现象

理解问题的症结所在

4.4 重构

重构：改善代码设计而不改变其行为的过程。

  • 重构应该在有全面单测套件的安全网中才可以安全修改既有代码
  • 重构或者修改功能，不能同时进行。 重构的同时决不能修改代码功能，同样也不能修复有缺陷的代码。(一次只做一件事)

4.5 签入

一次逻辑修改只做一次签入。方便快速回滚和定位代码问题。

4.6 审查代码

5. 反思

5.1 这到底是怎么搞的

  • 如果缺陷仅仅发生在少数用户身上，你就要反思是否还有其他问题？
  • 一个你以为会失败的 case，结果却成功了

5.2 哪里除出了问题？

五个为什么？

  • 我们已经做到了么？
  • 根本原因分析。责备没有用
  • 需求是否正确，是否是模糊的，误解了
  • 架构或者设计。有没有正确按照设计来做
  • 测试。测试覆盖率足够么？
  • 构造

5.3 它不会再发生了

  • 自动验证，检查是否存在问题
  • 和同事交流
  • 重构代码避免被不正确使用
  • 过程。检查工作过程

5.4 关闭循环

编码规范；测试规范；文档规范；报告/跟踪过程；设计指南；性能需求

6. 发现代码存在问题

6.1 缺陷追踪

  • 使用缺陷追踪系统。
  • 缺陷报告。具体，明确，详细的。
  • 环境和配置报告。自动收集环境和配置信息，不要指望用户

6.2 与用户合作

  • 简化流程
  • 自动化
  • 提供多种选择
  • 尽量简单
  • 模板不要死板
  • 尊重用户隐私

有效的沟通：

  • 心智模式。从用户角度设想一下
  • 和非技术人员沟通
  • 发布缺陷数据库
  • 隐私问题；提供反馈；拜访用户

6.3 与支持人员协同工作

学会沟通；和 QA 搞好关系，以便在修复缺陷的过程中得到帮助。

7. 务实的零容忍策略

7.1 缺陷优先

早期修复缺陷是一个好的策略：

  • 可能发现缺陷的过程（比如测试、代码审查、用户使用等）要连续贯穿整个开发过程

  • 缺陷修复优先于其他任何事情

  • 质量底下具有传染性。

  • 破窗理论。发现缺陷就立马解决，不要留破窗户

7.2 调试的思维模式

既要完美，又要实用。接近零容忍，但是用务实的心态去实现。

7.3 自己来解决质量问题

面对大量bug 如何摆脱困境？

  • 没有灵丹妙药。
  • 停止开发有缺陷的程序。阻止事情恶化。
  • 从不干净的代码中分离干净代码
  • 缺陷分类
  • 缺陷闪电战。集中较短时间专门修复缺陷

8 特殊案例

8.1 修复已经发布软件

集中精力减少风险。

8.2 向后兼容

将确定兼容问题加入到你的缺陷修复检查列表中

  • 提供迁移方法
  • 实现一个兼容模式。比如 word 就是这么做的
  • 提供预警。java api 升级
  • 不修复。极少数情况是一个务实的方案

8.3 并发

简单和控制

让并发软件中问题更少地发生不是一个可取修复办法。 修复并发缺陷时，避免实用 sleep 方法。

8.4 海森堡缺陷

观察者效应。尽量减少收集信息带来的副作用

8.5 性能缺陷

  • 寻找瓶颈。性能分析器。通过检查代码有时候预测瓶颈是不可靠的。
  • 没有瓶颈呢？是否是资源耗尽；垃圾收集；缓存丢失等

8.6 嵌入式软件

仿真器；硬件还是软件问题；

8.7 第三方软件缺陷

  • 不要太快去指责。首先怀疑你自己的代码
  • 报告别人代码中的缺陷。慎重自己直接修复
  • linux 法则：眼睛足够多，bug 无处藏
  • 报告问题：检查文档；尽可能给出足够信息

9. 理想的调试环境

9.1 自动化测试

  • 结果明确，通过还是失败
  • 环境独立
  • 所有测试可以独立运行
  • 全面覆盖

9.2 源程序控制

  • 合理使用代码分支
  • 坚持分之单一层级
  • 设计 CI 构建所有正在活跃的分之
  • 小的修改更加容易理解，合并和撤销
  • 不要一次合并多个分之

9.3 自动构建

  • 自动化构建整个过程，从开始到完成。
  • 持续集成
  • 静态分析(lint工具)。不要依赖未定义行为；谨慎对待编辑器警告

10. 让软件学会自己寻找缺陷

10.1 假设和断言

fail early，使用断言保护代码。

契约式编程：

  • 先决条件。不如参数不能是空
  • 后置条件。调用之后保持的条件，比如一个 http addHeader() 方法调用之后 headers map 比原来多一个
  • 不变量。方法调用之前它的先决条件被满足就始终为真的数据。

支持开启和关闭断言功能。

软件在产品阶段应该是鲁棒的，在调试阶段应该是脆弱的。 断言是一个缺陷检测机制，不是一个错误处理机制。

10.2 调试版本

不要等待资源泄露表现出来，主动今早地检测它们。

11. 反模式

11.1 夸大优先级

质量差才是导致大量缺陷的原因。

  • 定期清理缺陷
  • 控制优先级
  • 不要使用数字表示优先级

11.2 超级巨星

巨星效应会破坏团队。一开始匆忙实现看似非常高效率(所以被称为”巨星”），但是遗留了一堆棘手的烂摊子。

  • 确保完成就是完成，需要功能被测试过了，检查过了，记录文档了。
  • 任务分解为小任务
  • 自负自责。谁搞得 bug 谁负责修理它。（有时候你可能要考虑拍屁股走人了，比如一堆 c 艹的烂摊子？？？）

11.3 维护团队

最终开发和维护都要由一个团队来完成，保持连续性。不要区分开发和维护团队。

11.4 救火模式

退一步，找出根本原因，再去解决问题

救火模式永远也不会修复任何质量问题。

11.5 重写

从心理学角度来看，开发新代码比重写旧的代码让人更加舒服。天生乐观会让我们低估了复制旧功能要付出的精力和时间。 避免彻头彻尾重写，增量式重写代码。

11.6 没有代码所有权

集体代码所有权（极限编程）

11.7 魔法

任何你不理解的事情都可能隐藏有缺陷。唯一的方法就是纪律，把你不理解的事物都当成缺陷。