找到根因，才能从根本上解决问题

找到根因，才能从根本上解决问题

找到根因，才能从根本上解决问题

源自我参与的一个项目在用户那里出了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思于家中床前

作者：铭毅天下

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。