[韩小明]调试与审案: 切勿"屈打成招"

昨日看《神探狄仁杰》，看到曾泰（一个县令）差点使用大刑来逼嫌疑人招供。突然对“屈打成招”这四个字有了兴趣。所谓屈打成招，表面上是使用重刑，让受刑人，因为忍受不住刑讯，而最终将隐瞒的“实情”全部透露出来。可是大家都知道的事实在于，所有人都承受不住重刑！一旦冤枉好人，后果不堪设想。

屈打成招的背后，隐藏的是县官对查案中搜索证据能力不足的表现（当然了，那种因为受贿，强制受害人认罪的，咱们不考虑）。县官往往在一些表面证据的指引下，直接认定嫌疑人就是罪犯。因而动用大型！所以现在法律上一般都是重证据而不重口供。

上面是一个用例图。县官往往容易忽略自己的搜索证据的职责，所以才导致很多嫌疑人大呼冤枉的事情发生。所以说“搜索证据”和“屈打成招”正是截然不同的两种审案方式！

我们平时调试软件的时候，也经常有忽略方法，盲目上重刑的现象。最典型的情况是因为有多个模块，而错误出现在不同人实现的模块调用上。

你就是那个被调用的模块的实现者，现在让你来修改BUG，你第一怀疑的是什么？稍微经验丰富的人，有一句话会告诉你：先怀疑自己！可是很多人刚开始都会选择怀疑别人。可能怀疑基础模块出问题了，也可能怀疑调用者错了，还有甚者怀疑编译器错了。我和一位同事因为这个打过好几次赌，基本每次都是我赢。可每次他都先怀疑其他地方出问题了。

在那种错误场景能反复出现的情况还好，如果是偶现的BUG，那就更容易冤枉人了。在没有错误的模块里反复找来找去。当发现不了问题的时候，还是继续找。这种冤枉时间一般能搞个2天左右。2天之内能放弃跳出来已经很不错了。好在经过这2天，他一定能够吸收到足够的教训了。

我们继续说说调试。我以为，调试和查案是一样的。

第一、需要反复地审查案发现场。不要一开始就直接猜测什么地方有问题。现场是最好的开始。

当然了，和真正的案发现场一样，很可能你发现的不是第一案发现场。这种情况在访问内存越界的情况下，时有发生。由于内存数据发生了错位，等到真正抛出异常的时候，已经不是真正案发的时候了。大家经常怀疑编译器出错的时候，大部分也是这种情况，经常发现，明明2×2应该等于4，可偏偏结果不是！所以这个时候，关键在于找到第一现场。

如果一条线索不行了，再回过头来，从现场寻找另外的线索。

第二、线索要重证据。证据是什么？证据就是程序运行过程中留下的状态。将中间状态的数据记录下来，进行对比，看看到底什么地方出问题了。这才能真正发现问题。

第三、排除法很有用。将一些认为没有可能的线索放弃。这样大部分时候可以节省时间。但是如果最终行不通，需要重新拿起这些被放弃的线索。

第四、推理加证据的方式很多时候可以加快速度。有些时候，并一定能够第一时间发现证据。但是，可以凭着经验，先假设某种情况的发生，然后再顺着这条路去找证据。这样往往能够加快速度。充分利用程序员的经验。

第五、定案要重视证据链。证据往往不是孤立的。很多时候，如果我们只关注某一个证据，而忽略了很多其他不合理的地方，那么我们最后的结果往往就是没有修改彻底，最经常的结果就是，遗漏罪犯！将每个细节解释完整，BUG才能修改彻底啊。这个时候，可以进行现场重演的方式来进行验证。

调试，就是在软件中查找BUG的罪魁祸首，并给其定罪。在这过程中，最关键的两点是：问题解决、效率要高。盲目地屈打成招的方式只能让我们迷失方向。好在软件的调试，以最终的测试为监督，就算屈打成招也没用。可是，这当中失去的时间，谁来弥补呢？

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1476271