分而治之

二分法的应用与局限性

尊敬的 KV：

我们许多新来的开发人员——那些只使用过 git 的人——似乎只能通过使用 git 的 bisect 命令来查找代码中的错误。这令人担忧，原因有二。首先是，通常——一旦他们找到导致问题的更改位置——他们不理解原因，只知道它发生在版本 X 和 Y 之间。其次是，他们似乎不理解以这种方式调试的局限性，这或许更应该由您而不是我来向您描述。您是否发现这种做法越来越普遍，并且可能削弱了良好的调试能力？

被二分法肢解

尊敬的被肢解者：

正如 KV 的忠实读者现在所知，几乎所有新工具都是福祸相依，快速二分查找一组更改的能力也不例外。自动化接管了繁琐的工作，例如检出更改、构建系统、运行测试并查看测试是否失败，如果测试没有以正确的方式失败，则再次执行所有这些操作，直到找到引入错误的更改，这绝对是一件幸事。您希望这种类型的工作自动化，因此，在这种情况下，它是一种祝福——一种有限的祝福，但仍然是一种祝福。我的意思是，它又不是天上掉下来的馅饼，不是吗？

您要求我抱怨的是（您是在要求我抱怨，对吧？），这种工具如何造就懒惰的思考者，并由此延伸，造就懒惰的工程师。好吧，甚至在我们讨论拥有这种自动化是否会导致懒惰之前，就有很多问题需要讨论。

只有当您有一个被充分理解的错误，并且该错误以 100% 的一致性发生，以便二分法可以工作时，二分法等工具才非常有用。如果您遇到海森堡 bug 或类似微妙的问题，这些问题只会偶尔发生，那么二分法就毫无用处；而且，虽然我们不希望我们的系统中出现任何错误，但我们知道这些微妙的错误是最难修复的，也是那些真正让我们批判性地思考我们正在做的事情的错误——我们中的一些人。

定时错误、分布式系统中的错误以及我们在构建日益复杂的软件系统时面临的所有难题，目前还无法通过简单的二分法来解决。通常情况下，为一个复杂的问题编写一个可用的二分法测试（您必须编写该死的测试才能让二分法告诉您哪里发生了错误更改）所花费的时间，可能比在树的顶端分析问题所花费的时间还要长。

开发人员经常未能理解的另一件事是，该错误可能与任何先前的更改无关；它可能就在他们眼前，反过来盯着他们，以橙色显示在黑色背景上。我曾看到几位开发人员绝对确信该错误是“别人的问题”，他们一遍又一遍地运行二分法，最终才意识到实际问题出在他们最新的、未提交的更改中。在调试会话中嘲笑别人是不公平的，而且对于 KV 来说，这会危及生命和肢体，但这仍然非常诱人。

二分法为所有开发人员提供的仅仅是另一种查找代码中错误的工具。当然，该错误必须易于测试，可能不能在分布式系统中，也不能是定时错误或海森堡 bug，但这仍然比手工查找这些更简单的错误或编写自己的脚本来执行 bisect 将要执行的操作要好。

这个工具会让我们变笨吗？可能不会。它所做的也许是帮助经验较少的开发人员找到错误；但是，如果该开发人员希望学习，该工具并不会阻止这一点，这就是为什么这样的工具对某些人来说是福音，对另一些人来说是缓冲。

Kode Vicious，凡人称之为 George V. Neville-Neil，以编写网络和操作系统代码为乐，并以此营利。他还教授有关编程各个方面的课程。他的兴趣领域是代码探险、操作系统和重写您的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学计算机科学学士学位，并且是、Usenix Association 和 IEEE 的成员。Neville-Neil 是与 Marshall Kirk McKusick 和 Robert N. M. Watson 合著的FreeBSD 操作系统设计与实现（第二版）的作者之一。他是一位狂热的自行车爱好者和旅行者，目前居住在纽约市。

最初发表于 Queue 杂志第 19 卷第 3 期—
在数字图书馆中评论本文

更多相关文章

Charisma Chan, Beth Cooper - 在 Google 的分布式系统中调试事件
本文介绍了 2019 年对 Google 工程师如何调试生产问题进行的研究结果，包括工程师在不同组合中使用以有效调试的工具类型、高级策略和低级任务。它考察了用于捕获数据的研究方法，总结了生产调查的常见工程历程，并分享了专家如何调试复杂分布式系统的示例。最后，本文将这项研究的 Google 具体内容扩展到提供一些您可以在组织中应用的实用策略。

Devon H. O'Dell - 调试心态
软件开发人员花费 35-50% 的时间来验证和调试软件。调试、测试和验证的成本估计占软件开发项目总预算的 50-75%，每年超过 1000 亿美元。虽然工具、语言和环境减少了花在单个调试任务上的时间，但它们并没有显着减少花在调试上的总时间，也没有减少调试的成本。因此，过度关注开发过程中消除 bug 是适得其反的；程序员应该将调试视为一种解决问题的练习。

Peter Phillips - 使用跟踪增强调试
创建用于运行旧程序的模拟器是一项艰巨的任务。您需要彻底了解目标硬件以及模拟器要执行的原始程序的正确功能。除了功能正确之外，模拟器还必须达到以原始实时速度运行程序的目标性能。实现这些目标不可避免地需要大量的调试。这些错误通常是模拟器本身中的细微错误，但也可能是对目标硬件的误解或原始程序中实际已知的错误。（原始程序的二进制数据也可能已微妙地损坏或不是预期的版本。）

Queue 读者 - 又一天，又一个 Bug
作为本期关于程序员工具的一部分，我们在 Queue 决定就调试主题进行一次非正式的 Web 投票。我们请您告诉我们您使用的工具以及您如何使用它们。我们还收集了一些关于那些难以追踪的 bug 的故事，这些 bug 有时会让我们想到换个职业。