无奈而又苦逼的二分版本号回退法定位新引入的bug！！！

昨天測试人员和开发者都发现， 某新版本号有严重的bug.  群里已经開始嚷嚷了， 但没有谁知道是谁引入的问题。本来呢， 这个问题不应该是由我去定位， 但主管让我帮定位一下， 毕竟时间太紧急， 必须尽快解决， 開始的时候， 我还是有些压力的跟有经验的员工讨论后， 也没有比較好的办法， 所以， 仅仅能自己想办法了。为了方便叙述，
以下我会对实际场景进行抽象。

经我亲自验证发现， 100版本号绝对ok,  300版本号却有问题， 也就是说， 是这个之间的某个版本号引入了bug.   由于这个问题比較难以定位， 所以查看配置库的改动记录就成了当前唯一可行的办法。

可是， 细致重复看了这个区间的改动记录， 没有发现有可疑的异常情况， 所以仅仅能採取二分查找验证了， 仅仅是每次验证都至少要15-20分钟， 并且每个步骤都不能出错。问题是， 模块较多， 是回退某一模块还是回退全部模块呢？ 依据bug的现象， 确实难以分析出出问题的模块所在。

怎么办？ 我和另外一个有经验的员工首先分析了出问题可能性最大的两个模块， 昨天下午開始， 对当中的一个模块（第三方库）进行版本号回退測试， 没有发现有异常， 并且单一模块回退多了， 非常easy造成编译只是（其它模块不回退）， 各种郁闷和苦逼啊 搞到凌晨还是没有搞出来， 好吧， 太累了， 先回家睡觉。

今天呢， 我必须单独搞定这个问题， 于是我对另外一个可疑模块进行回退測试（其余模块都採用最新代码和库）。 边回退， 边记录结果。我取这个可疑模块的第200个版本号进行測试， 发现ok,  这个时候， 就有点高兴了知道问题基本就锁定在这个模块了， 于是花了3个多小时进行二分回退验证， 搞了7， 8次吧， 最后锁定了改动引入问题的版本号，
铁证如山。结果查看改动记录后， 傻眼了， 该代码提交人只改了一个单词。 好吧， 尽管我不清楚问题的详细原因， 但我证据充分地定位到了问题， 让相应的人改动（最后他发现， 也确实有问题）。

二分版本号回退法是最无奈的办法。 哥们， 以后改动问题要注意啊， 不要引入新的问题搞我辛苦一大天， 还搞到凌晨。

最后，要强调一下： 定位问题， 思路非常重要， 不然搞几天都有可能搞不出来， 自己误导自己。  这次定位bug, 尽管过程非常繁琐非常苦逼，但还是非常开心的， 定位出了一个严重的bug, 能让版本号顺利公布。

噢耶

补充说明： 有的网友反馈， 你能够加日志定位啊。 事实上， 原bug的现象就是： 该系统没有日志输出