项目中几个紧急Bug的处理及反思

【背景】
项目紧急验收阶段，由于后期需求修改大，测试非常不充分，导致后期Bug非常多。
以下Bug大多是在夜里10点到凌晨5点修改的，神志不清的情况更要注意正确性。

【典型Bug及分析】
1.任务暂停再启动后的逻辑处理Bug。
1）由于Calc模块是根据inner模块的传入的ID值进行计算并存入数据库的，所以每次任务暂停后也必须将原有存储过ID值的Map容器清空才可以继续存入下一次的值。
2）但是又由于Outer模块和inner模块之间通过Single-direct设备进行传输，如果程序收到指令立即清除Map，并将新值存入Map也有bug。Bug的原因就是未考虑Single—direct设备传输慢的问题。
所以，最终的方案就是所有的ID值从数据库中读取，以数据库中的为准。这样，就有效避免Single-direct设备慢的问题。

2.多任务下发崩溃问题。
单步调试发现是类似接收端的Buffer原因导致溢出。但根本原因，由于涉及多处自己封装的类，且原作者已经离职，很难继续跟踪排查。
最终换了思路，由原来Inner模块实现的监听并读取数据的操作。改为Inner模块仅负责监听，Inner-CEF模块接收Inner发出的行号，完成数据的查询和组织。这样就有效缓解了传输压力，避免传输Buffer导致溢出的问题。

3.最新包内外网无法通信问题。
该问题是数据由于问题2改动引发的问题。修改问题2的时候，涉及Inner模块与Inner-CEF模块传递数据，原有代码中传输的Buffer设定为64个字节。而行号定义的Buffer150个字节，我就想当然的将Buffer立即修改为150个字节。
殊不知，最终查Bug才发现，该字段64个的定义涉及多处调用，而其他都是使用的64个字节。且查询的行号也就在20个字节之内，定义为64个字节的buffer绰绰有余。
对于紧急情况下该问题的处理，事实也证明了我的思路的正确性。也就是说，改动下的情况，完全可以通过Beyondcompare工具比对代码或者svn、git查看修改记录，发现问题的根源所在。不必短时间内研究问题的逻辑。逻辑问题可以事后花时间去研究。

4.CEF对PNG大写格式的不支持问题。
花了很长的时间，写好了资源、ID、路径之间的对应关系，但是仍然发现打开新包的时候无法加载图片。无法加载无非如下的几个原因：
1） 图片在res文件夹下不存在；
2）图片已经存在，但图片的ID、路径信息不正确，即对应关系错误；
3) 图片已经存在，但图片格式不支持。（很难发现）
也是在打开应用，看到了几个图标能够打开，而绝大部分打不开的情况下才想到了3）。
最终发现程序中不支持对大写PNG格式图片的处理，加一句转换即可。

5.静态加载DLL或者动态加载DLL区别在程序中的体现。
程序中使用了第三方公司的Key证书。该公司提供了静态加载与动态加载的两种方式及Demo接口使用规范。
动态加载DLL的好处，相比静态加载就是减少程序的依赖，即：如果Key有所升级，只需要替换DLL，我们的程序无需再次编译。
而静态加载，需要包含.h和.lib文件，第三方公司的任何修改，势必我们都要重新编译工程、重新打包程序。
究其新程序无法获取环境变量设定系统路径下的DLL，根因待查。

【反思】
1.打最新包注意事项。
1）打包的程序都是单个测试过的没有Bug的最新版本。
2）打包注意桌面快捷方式图标、卸载程序图标关联等细节问题。
3）打包的单个程序确保都加载了最新的res资源，res资源中有最新的js和html前端代码的改动。
2.改动别人写的代码中的Bug如何避免再次引发Bug？
1）如果原作者在，最后电话确认下改动方案的可行性。
2）梳理好逻辑，逻辑通了以后再开始写代码。
3）注意程序的接口及通信层面的细节，每个原有接口的修改，都要看下有没有其他接口的调用，避免改动引发。

2014-11-13 12:29 思于家中床前

作者：铭毅天下
转载请标明出处，原文地址：http://blog.csdn.net/laoyang360/article/details/49816107
如果感觉本文对您有帮助，请点击‘顶’支持一下，您的支持是我坚持写作最大的动力，谢谢！