学会利用差异对照法快速定位bug所在的模块

        在软件开发中， 遇到bug时， 不同模块的开发人员经常相互扯皮， 我门说是你们的问题， 你们说是我们的问题， 结果呢，两方人都不愿意花精力去仔细定位， 两方都希望对方先分析一下， 然后确定bug所在位置。 相互踢皮球嘛


        在实际开发中， 这也见怪不怪了。大家都很忙， 有时候需要一些特殊的方法， 确定问题所在的模块， 而不是一有问题， 就去死抠代码， 这样会累死的。

        前面我们讲过， 追溯配置库变化来定位bug.  实际上也是利用到了差异对照法。 下面， 我来简要说说我所遇到的两个问题， 我比较快速地定位到了问题的模块， 用强有力的证据表明， 这个bug不是我们模块引起的， 还请其他模块同事来定位并解决。

 

       场景一： 

       在第100个版本中， 低层和中间层一起， 没有出现问题， 而在第101个版本中， 出了某个问题。 由于我们是中间层的， 所以这类问题一般会先走到中间层开发人员分析。 如果按照常规的方法， 肯定是要去具体分析为什么有这个bug. 后来我想， 这样太麻烦， 我采取的方式是： 把第100个版本的中间层和第101个版本的低层结合起来， 如果还有问题， 那么基本上就说明是低层变化了什么才导致这个bug.  最后， 我用上述方法测试， 并与低层同事交流， 他们认为我的分析可行， 他们随即深入定位， 果然，
是低层改了东西才导致那个bug.

       场景二：

      在第200个版本中， 低层和中间层合起来会产生某个bug.   自然， 这个问题由中间层开始定位， 定位了一段时间， 没有发现中间层有问题， 问题暂时遗留。 结果， 在第201个版本中， 该bug居然莫名其妙地不存在。  不能因为后一个版本没有问题， 就稀里糊涂地认为问题解决了， 还是要去定位一下当时的第100个版本为什么存在问题。  我当时是这么做的： 我把第201个版本的中间层和第200个版本的低层结合起来， 发现bug依然存在， 由此基本可以证明, 第200个版本中的bug与中间层无关，
于是将问题转给低层的同事进行分析。结果证明问题刚好就是在低层。

       我想说的是， 大家都是一个大的项目团队中的人， 将问题分析出来， 走给对应模块的人去分析解决， 这和推卸问题完全是两个不同的概念。 用比较可靠的证据来证明某bug是自己某块的问题或者非自己模块的问题， 这本身就是一种负责人的表现， 这是高效的工作方法。

      本文不是探讨如果推掉问题， 而是探讨如何定位问题的模块。高效快捷， 何乐而不为？ 

      还是那句话， 作为一个软件开发的人， 要灵活灵活再灵活， 找各种各样的方法， 想方设法， 直接法， 间接法， 这法那法， 少找借口。 其实， 何止是软件开发， 哪行哪业不需要灵活？  我们要转变书呆子模式， 到社会上来， 学东西非常重要（过程）， 但解决问题更重要（结果）