3、利用差异来缩小问题根源的范围
假如有两个“同样”配置的机器，一台有问题，另外一台没有问题，那么要找出那台有问题机器出问题的原因，可以关注一下两台机器有什么差别。虽然配置看起来一样，但他们肯定有差别。找出这些可能和问题相关的差别，利用上一节介绍的实证性分析的方法来证明你的假设。
另外一个例子，如果你开发中的软件，版本001没有问题，而版本002有问题，那么就看看这两个版本之间有什么差异，比如通过SCM来看看都改动了哪些文件，或者使用的第三方库是否发生了变化等。
4、利用二分法
我们都知道二分查找的效率很高。同样我们也可以利用二分法的一般原理来缩小问题的范围。还是以上面的那个例子，假如版本001没问题，而版本008有问题，那么怎么快速找到问题是在哪个版本里面引入的呢。最直接的办法，从版本002一直试到008，但是这样效率就太低了。我们假设问题被引入后就不会自动消失，这样就可以利用二分法来找到查找问题被引入的第一个版本。我们先看版本005有没有同样的问题，如果有，那么问题就在版本002-004之间引入的，然后在继续用同样的方法找下去，最多找3次就能找到首次引入这个问题的版本，然后就可以看看那个版本里面有什么改动，就可以把问题的根源缩小到这些改动上了。
这也是持续集成的思想了，每次提交代码都会触发一次构建和单元测试。如果构建或者测试失败了，问题的的根源就是上一次代码提交造成的，在问题被引入的第一时间修复这个问题要比过了几个版本后再修复要容易一些。
5、写出能重现问题的最短代码
如果软件的问题是由于第三方的库导致的，在向第三方库报告问题的时候，最好是能写出一个简单的程序来向其说明问题的发生条件，而不是把直接把你的软件的问题扔给第三方。
同样的，如果问题就是软件内部造成的，如果能写一个单元测试来重现问题，那么也能提高你测试和调试的速度，因为单元测试启动和运行的速度肯定比把整个系统启动起来的速度要快。任何时候，我们都要提高反馈的速度。
6、小结
在遇到问题的时候要先分析以缩小问题根源的范围，而不是直接就跳到代码里面去看哪里出错了（那些一眼就看出问题出错的地方除外）。如果问题在某个环境（这里的环境是各种可能因素的组合，比如OS，软件，第三方库或者系统）发生了，而在另外的环境没有发生，利用这两个环境的差异来找出可能导致问题的因素。利用实证的方法来逐渐缩小问题根源的范围，利用二分法或者其他策略来快速排除一些干扰因素。在找到问题的根源后，最好能写出一个单元测试来重现问题，它能提高测试和调试的反馈速度，也有助于向第三方描述问题。我相信本文介绍的方法大家都曾经使用过，我只是将大家都知道的内容简单总结了一下，希望能有些帮助。
