逻辑性错误出现后的杯具和启示

上个月发布了一个新的功能性需求，发布后快一个月了一直都没有什么问题反馈，用户也没有提示Bug之类的，但是上周有个用户突然说有一个他修改采购入库单据出现错误，错误的原因是他修改了入库单的产品明细的单位，听到这个消息我们的运维人员感到困惑，因为以前系统一直是不让修改入库单据的单位的啊，而且明细数据都是根据采购单据号直接取出来的啊，只有数量时可以更改的啊。所以实施人员赶紧自己验证了下，发现现在单位确实可以修改了。这下轮到我头大了，我在PRD数据库里查询了下这些出现问题的单据，发现居然有200多条了，而且还产生了月结，设计到了20多家用户，这下惨了。于是我赶快想了个办法，先尽快堵住这个漏洞再说，历史错误数据再慢慢想办法。想来想去发现只有在存储过程上拦截比较方便，因为已经周5了，重新发布新版本要冒太大的风险了，而且现在明令禁止在周5发布新版本，存储过程例外。

现在看来也只能选择发布存储过程了。因为我们的审核都是使用存储过程来执行的，这样我就在审核时，加上了一个判断，判断验收入库单据是否修改了采购订单的单位和单价，如果修改了就提示用户，并且不能通过审核。所以通过发布存储过程也算是堵住了漏洞。而且发布存储过程对用户影响相对较小，只需在数据库服务器执行即可，当然这是要建立在脚本经过了严格的测试之后，才能执行的。这样看来有时候一些逻辑放在存储过程中实现是比较有好处的。

这次的Bug也暴露出了一个问题，我在实现新功能时，对新功能产生的影响点没有考虑周全，测试人员测试时也忽略了这个点，大家都忘记了这么个小地方，说明我们的思维还是不够严密，写代码可能只需要1个小时，但是设计和测试应该比开发要花更多的时间，而且应该做的更加详细，全面。而且需要经过严格的审核，同时开发过程中我们也要做到互查代码，尽可能的减少Bug流到终端用户的手中。

转载于:https://www.cnblogs.com/kevinGao/archive/2012/09/10/2776043.html