找到根因，才能从根本上解决问题
源自我参与的一个项目在用户那里出了bug，当然非我的改动引发，是之前处理数据未考虑到异常。
一、Bug描述
公式即：优化数据=出口1flow1-出口2flow2，优化比例=优化数据/出口1flow1。
正如上表黄色标注所示，bug表象是优化数据为负值，优化比例为负值。用户一看还了得，还不如不去优化？
二、Bug临时补救方案
分析发现，不是所有应用识别都会出错，只有极其个别的情况。并且这种逻辑，近几年就跑出一回。所以，我们的方案是，当出口2flow2>出口1flow1的时候，就置出口2flow2
=出口1flow1。这样就绝对不会出现优化数和优化比例为负数的情况。
三、Bug补救后仍存在隐患
隐患1：所有上面的出口1、出口2的数据是从mysql数据库中读取的，包含合计数据。合计和应用1-9共用一套逻辑，所以导致纠错时，如果出现出口2比出口1大的情况，置出口2=出口1的数据。这样就会出现出口2列的应用1-应用9的求和与出口2合计不等的隐患。
补救隐患1：只有出口2列对应的合计行出错，真正的和应该等于应用1+…+应用9。想到的方案是不是从数据库中读取，而是进行应用1到应用9的求和。
补救隐患1后的隐患：我们保证了不出现异常数据，保证求和正确，用户看着没有问题，但作为工程师，就要扒一扒为什么会出现上面的异常数据？
四、找到根因
讨论分析发现，是我们的应用识别驱动问题出了问题，导致讲大量出口1的数据识别为出口2的数据。即是下图的分类识别数据出了错。
五、总结
很小很小的bug，但是带来很大很大的灾难性不可饶恕的问题，这种我们自身验证和测试是几年也跑不出这种异常数据的。但是，我们对异常的把控是做的远远不够的，其实除了常用的除数为0的情况，对于这种优化数据良不能为负数的情况也必须敲响警钟！
程序设计中要做出异常处理机制，或者跑出异常、或者打印错误日志，或者其他方法，但是一定要去做，要去处理，异常的场景考虑的越全面越好，异常的处理机制对应的越多越好。
谨记！
2014-9-21am10:30思于家中床前
作者：铭毅天下
转载请标明出处，原文地址：http://blog.csdn.net/laoyang360/article/details/39449391
如果感觉本文对您有帮助，请点击‘顶’支持一下，您的支持是我坚持写作最大的动力，谢谢！