Question

二分法是编程课中讲解递归函数时提到的概念，但其实这个方法在现实中往往用于排查问题。

记得有一次Android发版，测试人员发现，收银台突然就不能支付了，一点击支付按钮就崩溃。负责该模块的开发人员东瞅瞅西看看找不出崩溃的原因，最后一口咬定是后台MobileAPI有问题。

这件事上升到我这个层面，我当时就觉得很奇怪，首先，线上的版本是没有问题的，iPhone上也是好的，而且，据测试人员反映，Android的测试包前几天还是好的。那么基本可以断定：

1）与MobileAPI无关，肯定是这次迭代改出问题来的。

2）导致崩溃的改动，肯定就是这几天的代码签入导致的。

于是我使用二分法来查找问题。我们要查找的是，导致App支付崩溃的那次代码签入点。换句话说，找到App最后一次不崩溃的代码签入点。

首先看一下每日自动打包（DailyBuild）的服务器上备份的历史版本，如图11-1所示：

图11-1　打包服务器上的历史版本

也就是说，6月1号开始开发，6月30号最后一次提交代码。我们先以天为单位，找到崩溃发生的那个临界点。

1）我们先检查6月1号的包是好的还是坏的。如果6月1号的包是坏的，那么就是6月1号的某次提交导致了崩溃，我们直接在6月1号的提交历史中进行二分法排查。如果6月1号的包是好的，那就是1到30号之间的某天的包有问题。我们使用二分法，看一下15号这个包是好的还是坏的，如图11-2所示：

图11-2　使用二分法查找错误提交点

接下来会有两种情况：如果15号的包是好的，那就是说15到30号之间某天的包有问题，如图11-3所示；如果15号的包是坏的，那就是说1到15号之间某天的包有问题，如图11-4所示。

图11-3　使用二分法查找错误提交点

图11-4　使用二分法查找错误提交点

选择15号作为第一次二分法的时间点，帮助我们缩小了排查范围。以此类推，下一次二分法的点是7号或者22号。以此类推，逐步缩小排查范围。对于时间长度为30天而言，这么找5次就能找到出问题的那一天（2的5次方最接近30）。

2）在出问题的那一天，我们继续使用二分法，找出问题的那一次提交。这次二分法不再是以天为单位，而是以每次提交为单位。如果当天有100次提交的话，大约找7次就够了（2的7次方最接近100）。

虽然上述这种做法土了点，每次都是把那次签入相对应的整个App代码都签出，然后打包安装到手机上验证是否会有崩溃。但越是土办法越有效，我花了1个小时，就把问题定位在昨天下午的一次代码签入，开发人员误把一个if语句直接返回true而不走下面的业务逻辑，没有给一个变量赋值，所以点击按钮的时候因为那个变量为空而崩溃。

后来这个方法就推而广之了。有一次发版后，大量用户打电话反馈说不能登录——对于一个电商平台而言，不能登录意味着不能下单，没有生意做，这是绝对不允许的。

但奇怪的是，我们开发人员无论如何也不能复现问题，就这样猜着查了一下午原因，始终不得要领。直到傍晚下班前客服妹子的一个电话打了进来。预知后事如何，且听下文分解。