我在一次现场咨询电话中进入了相当大的未知代码库，并找到了问题……

加上我关于 git bisect run 的文章。它真的是一款非常棒的小工具。 https://andrewrepp.com/git_bisect_run

“git bisect”是我保持一种纪律的原因，即所有提交到“真实”分支的代码（无论你如何定义这个术语），都应该能够单独构建，并通过所有（当时已知的）测试，并且在某种程度上可以部署，也就是说，根据你所知道的它们应该能正常工作，即使你实际上并不想部署那个具体的版本。我将这一原则作为我的首要原则，高于“我应该能够看到每一份曾经写下的键盘输入”或者“我希望每一个最后的‘修复’提交”这类有时在这里被提倡的原则，因为这些原则会让bisect变得无用。 事实上，我并不经常使用bisect……但在你的源代码中保持这种纪律与防止代码回归和最初出现错误的纪律高度重叠。但当我最终使用它时，它每年只需一次就能为自己带来回报，因为我们为最大的、最令人头疼的问题找到了bisect方法。…

git bisect 是一个绝对强大的功能，每个人都应该了解。我一年中可能最多使用一两次，但它却能在一小时内修复一个错误，而不是花费几天或几周的时间徒劳无功。

并不是在抱怨二分法（bisect），它非常好。但在我看来，区分这本书中的哲学思想和思维空间方面（“规则”）与实际建议（“工具”）是非常重要的。 一个通过“我想要哪个工具”来思考问题的人（参见“git bisect 对我帮助很大”[1]），会比另一个通过“这以前不是能工作的吗？”[2]来做出相同决策的人处于巨大的劣势。 世界上充满了各种工具。试图在脑海中记住所有工具只会导致精神崩溃。首先应该接受哲学思想。 [1] 也包括像“使用时间旅行调试器”、“开启日志记录”等其他方法... [2] 例如“这种状态是非法的，问题出在哪里？”、“我们正在处理哪个命令？”

上世纪90年代，当我调试一些网络配置问题时，一位更年长的同事教给我一个更普遍的概念，这个概念是git bisect背后的思想，即“将故障系统与正常系统进行比较，并系统地消除差异以找到故障点”。这可以应用于软件或计算机硬件以外的事情。上世纪90年代，我和朋友拥有相同的喷气式摩托艇，我们共用一个拖车。当我们修理其中一辆时，有它的双胞胎在旁边进行比较非常方便。

在调试css时，二分法也很有用。 当你不知道页面上某个特定滚动或布局的问题出在哪里时，你可以在开发者工具中删除一半的DOM，然后检查问题是否仍然存在。 重复这个过程，这其实是一种基本的二分查找。 我经常惊讶于那些在LeetCode上非常厉害的人在现实世界中完全无法应用他们学到的知识，无论是编码还是调试，这总是让我想起用这个作为招聘工程师的指标是多么无用。

当你处理一个复杂系统时，也可以使用分而治之的方法。 比如，从A到B的流量可能会因为VPN等变得复杂。你可能会有源防火墙、源路由、源到路由器的连接、路由器上的路由、路由器上的防火墙、各种可能出错的VPN配置，而且在目标端也是一样的。很容易有15个以上的因素导致流量消失。 这就是为什么我们的操作手册建议在排查问题时首先在VPN节点上抓包。这是一个低努力、快速的步骤，可以确定流量在旅程的哪一段丢失——到VPN、通过VPN、到目标、回到VPN节点、通过VPN返回、回到源。然后你会发现流量在回到VPN节点时消失，你可以深入调查。 而这是一个在系统排查中非常强大的概念：能否…

二分查找是王道。系统地将问题分成两半，确定问题在哪一半，然后重复这个过程，这在非软件问题上也非常好用。我经常在排查汽车等问题时使用这个策略。