差异调试

回归错误是在软件中已经存在一段时间的功能中新出现的错误。在追查这些错误时，通常需要弄清楚软件中的哪些更改导致了这些错误的出现。查看这些更改可以提供关于错误所在位置以及如何修复错误的宝贵线索。这种调查形式没有一个众所周知的术语，但我称之为差异调试。

差异调试只有在我们对代码进行版本控制的情况下才能起作用，但幸运的是，如今这已经成为常态。但要使其有效地工作，还需要一些其他条件。我们需要可重现的构建，以便我们可以轻松地运行旧版本的软件。由于高频率集成，拥有较小的提交会非常有帮助。这样，当我们找到有问题的提交时，就可以更容易地缩小发生的事情的范围。

为了找到导致错误的提交，我们首先找到任何没有错误的过去版本。将此标记为最后一个正常版本，并将当前版本标记为最早的错误版本。然后找到这两个版本之间一半的提交，看看错误是否在那里。如果是，则此提交成为最早的错误，否则它成为最后一个正常。重复此过程（这是一个“半间隔”或“二进制”搜索），直到我们找到有问题的提交。

如果我们使用 git，那么git bisect命令将为我们自动执行大部分操作。如果我们可以编写一个测试来显示错误的存在，那么 git bisect 也可以使用它，自动完成查找有问题的提交的整个过程。

我经常发现差异调试在编程会话中很有用。如果我的测试速度很慢，需要几分钟才能运行，我可能会编程半小时，只运行最相关的测试子集。只要我在每次绿色测试运行后提交，如果这些较慢的测试之一失败，我就可以使用差异调试。这是非常频繁提交的价值所在，即使它们很小，以至于我觉得最好将它们压缩以用于长期历史记录。一些 IDE 通过自动保留比版本控制提交更细粒度的本地历史记录来简化此操作。