都说家丑不外扬，但是今天的bug深深地刺痛了我的心，从而让我决定不吐不快。医院客户，住院偶尔出现多收费的情况，同事没有找到原因，让我远程排查一下。由于今天事情不是很多，加上我的远程工具有点问题，于是我决定直接去现场。
当我辗转地铁加公交，历时两个多小时赶到现场，看到客户的截图后，我傻眼了，这根本不是多收费那么简单，医生开出的“心电图检查”医嘱，在护士界面，费用变成了“开腹恶性肿瘤激光治疗”，相信任何一个病人看到自己费用清单上面错误显示了“开腹恶性肿瘤激光治疗”都会火冒三丈的。
我立马投入到了原因分析中，因为病人的数据还保留了原样，所以我首先对数据进行分析。查看医生医嘱本发现医嘱为心电图检查，说明医嘱是正确的。查看检查申请单发现申请单确实是“心电图检查”，说明申请单也是正确的。检查申请单对应的诊疗医嘱发现为检验项目“血清检查”，从而确定诊疗医嘱数据出错了。继续检查护士对应的费用医嘱，发现费用医嘱为“开腹恶性肿瘤激光治疗”，逆向分析费用的来源，理清楚了数据出错的流程。医嘱复合的时候，由于医生医嘱为检查医嘱，系统把诊疗医嘱里面“血清检查”的ID作为诊疗项目ID，找到了对应的费用“开腹恶性肿瘤激光治疗”，从而在护士站显示了“开腹恶性肿瘤治疗”。
接下来，就是分析，检查申请单对应的诊疗项目为什么会变成了检验项目。后面需要做的就是排除检验系统的程序了。大体看了一下检验系统的控制流程，没有发现明显的错误，当然了这也符合这种错误出现的概率比较低的现象。但是，直觉告诉说，系统肯定是存在bug的。随即，一行一行的代码分析。
医生医嘱跟诊疗医嘱是通过医嘱本序号关联的，从前面分析的数据结果来看，这种关联关系明显是错误的，也就是说，很大一种可能是检查开单和检验开单生成医生医嘱的时候，获取到了相同的医嘱本序号。通过分析检查开单和检验开单代码，发现，获取医嘱本序号的入口是统一的，都是调用了返回种子值的存储过程，由于我知道存储过程获取种子值的低版本是存在并发bug的，直觉又一次告诉我，这个客户的存储过程是存在并发bug的，通过检查，果然发现存在此bug。
通过检验项目“血清检查”逆向查找检验申请单，发现对应的申请单包含46条明细检查。通过检验申请单查找对应的46条诊疗项目，发现其中就有这条出错的“血清检查”项目。通过检验申请单查找对应的医生医嘱发现只有23条医嘱，其中最后一条医嘱就是“心电图检查”。我开始兴奋起来了，因为真相离我越来越近了。
我还原出来的当时检验开单情景是，检验申请单在生成医生医嘱的时候出错了，又一次检查了医生医嘱和诊疗医嘱的数据持久化保存，确实在同一个事务里面，不应该出现这样的错误，但是从数据来看，确实是事务没控制住。
再次检查事务控制，终于找到问题了，虽然医生医嘱和诊疗医嘱的数据持久化保存在同一个事务里面，但是当事务失败的时候，并没有执行事务回滚操作。也就是说检验申请单生成医生医嘱的时候，当生成到第23条记录的时候，刚好碰到了前面分析出的存储过程并发bug，因为检查申请先占用并保存了取到的相同医嘱本序号，造成此处的操作发生了主键冲突错误，从而事务失败，同时此处没进行失败后的事务回滚，当后面事务再次执行的时候顺带着把前面生成的22条医生医嘱和46条诊疗医嘱持久化进了数据库。
似乎可以定案了，但是还有个问题困扰着我，诊疗医嘱的主键是医嘱本序号和诊疗项目ID，按理说，检查申请单生成的诊疗医嘱也是会存在的，但是此处表现出来的是，此医嘱本序号只对应了检验项目“血清检查”。申请单对应的诊疗医嘱到底是没生成还是生成后又被删除了呢？
继续排除检查申请单生成医生医嘱和诊疗医嘱的代码，发现事务控制是正确的，从而说明了，“心电图检查”对应的诊疗医嘱是被后来删除的。再次去排除检验申请单生成医生医嘱和诊疗医嘱的代码，发现，诊疗医嘱数据持久化之前，先删除了医嘱本序号对应的所有诊疗医嘱，再插入检验申请单对应的诊疗医嘱，从而解释了，“心电图检查”对应的诊疗医嘱丢失的现象。
至此，这次bug也就完全分析出来了，接下来要做的就是修复存储过程并发bug，并控制好检验申请单开单的事务。
我仅仅用了四个小时，就把问题分析了出来，客户对我进行了高度的肯定，但是我却非常的不舒服，这个bug完全是我们程序员自己埋下的，单独摘出来看程序的问题，可能很多人觉得，不是很严重。但是从“心电图检查”变成“开腹恶性肿瘤激光治疗”来看，这是一个不可饶恕的bug。也许很多同事会觉得我是大牛，因为很多困扰他们的问题，我都会给分析明白，但是我想说的是，世上哪有大牛，一切都是厚积薄发。真的应了那句话，“细节决定成败”，写程序真的是一件很严谨的事情，我们需要好好反思，一个好的产品需要我们用心去做，需要我们敬畏每一行代码。
预览时标签不可点收录于话题#个上一篇下一篇