Debugging 调试的标准方法

调试问题的标准方法是什么？这似乎是一个相当宽泛的问题，你们中的一些人回答说“这取决于问题”，但我认为我们中的许多人是凭直觉进行调试的，实际上还没有尝试过使用我们的流程。这就是为什么我们说“视情况而定”

最近我被迫说出我的流程，因为我和几个开发人员正在处理同一个问题，我们用完全不同的方式调试它。我想让他们明白我想做什么，反之亦然

经过一番思考后，我意识到我的调试方式实际上相当单调。我将首先尝试可靠地复制问题（尤其是在本地计算机上）。然后通过一系列的消除（我认为这是与问题相关的）尝试识别问题

其他人试图用完全不同的方式来做

所以，我只是想知道你们这些家伙到底做了些什么？如果你必须用文字形式化它，你会说你的调试过程是什么

---

顺便说一句，我们仍然没有发现我们的问题=）

当我遇到一个我无法弄清楚的bug时，我喜欢为这个问题建立一个模型。复制问题代码部分，并开始从中删除功能，一次一个。每次删除后，对代码运行单元测试。通过这个过程，您要么删除带有bug的特性（从而找到bug），要么将bug隔离到包含问题本质的核心代码段。一旦你弄清了问题的本质，解决起来就容易多了。

我的方法根据我对手头系统的熟悉程度而有所不同。通常我会这样做：

如果可能的话，复制故障

检查故障状态以确定故障的直接原因

如果我熟悉这个系统，我可能对根本原因有一个很好的猜测。如果没有，我开始通过软件机械地追溯数据，同时挑战软件所做的基本假设

如果问题似乎有一个一致的触发器，我可以使用调试器手动遍历代码，同时挑战代码所做的隐式假设

当然，追根溯源是事情变得棘手的地方。在这一点上，拥有一个转储（或者更好地说，一个活动的、中断的流程）是非常宝贵的

我认为调试过程中的关键点是挑战预先的概念和假设。我或同事发誓在该组件中发现bug的次数非常多

---

我直觉更敏锐的朋友和同事告诉我，当他们看着我调试或让我帮他们解决问题时，我很迂腐

我也非常喜欢使用消除过程。排除变量极大地简化了调试任务。这通常是第一件应该做的事情

另一个真正有效的方法是，如果可能，回滚到上一个工作版本，然后重试。这可能是非常强大的，因为它为您提供了坚实的基础，使您能够更加小心地进行操作。这方面的一个变化是，让代码工作到一个点，使用更少的功能，而不是不使用更多的功能

---

当然，重要的是不要只是尝试。这会增加你的绝望，因为它永远不会起作用。我宁愿跑50次来收集关于这个bug的信息，也不愿疯狂地挥杆，希望它能起作用

我通常首先根据手头的信息形成一个假设。一旦这样做了，我会努力证明它是正确的。如果它被证明是错误的，我从一个不同的假设开始

通过这种方法，大多数多线程同步问题都可以很容易地得到解决

---

此外，您还需要很好地了解正在使用的调试器及其功能。我在Windows应用程序上工作，发现windbg在查找bug方面非常有帮助。

将bug简化为最简单的形式通常可以更好地理解这个问题，并在必要时增加让他人参与的好处

设置一个快速复制场景，以便有效地利用您的时间来测试您选择的任何低磷症

创建工具以快速转储环境以进行比较

在日志记录处于最高级别时创建和复制错误

检查系统日志是否存在任何警报

查看文件日期和时间戳，以了解问题是否可能是最近引入的

在源存储库中查找相关模块中的最新活动

应用演绎推理并应用原则

---

愿意退后一步，从这个问题上休息一下。

我从网上或一些我想不起来的书上选的（可能是编的或…）

调试101：

• 复制
• 逐渐缩小范围
• 避免调试器
• 一次只改变一件事

心理方法：

• 橡皮鸭调试
• 不要猜测
• 不要太快责怪工具
• 了解问题和解决方案
• 休息一下
• 考虑多种原因

防虫方法：

• 监控你自己的错误注入习惯
• 尽早引入调试辅助工具
• 松耦合与信息隐藏
• 编写回归测试以防止再次发生

技术方法：

• 惰性跟踪语句
• 查阅第三方产品的日志文件
• 在web上搜索堆栈跟踪
• 以合约方式引进设计
• 一笔勾销
• 间歇性错误
• 爆炸局部性
• 介绍