记录一次软件Bug发生的过程

结束一周的紧张工作，难得的休息时光，坐在电脑前浏览博客、听听歌、看看大片，这也算是一种享受。

因为年度的开发任务已经开始了，所以最近会特别忙，新人的成长又没有想象中的好，经常在他们身上看到自己去年的影子，对什么都不了解，自己去学习这个框架又不知从何入手，问也不知怎么问。当时项目组也缺人，就这么加入项目，开始了不断地加班不断学习的过程。这种成长的经历记忆深刻。现在带新人，也会从去年自己的经历吸取教训，巴不得把自己了解的所有的东西都教给他们。

言归正传。上周一，一上班就接到任务，在这里暂且称其为A需求吧，是在原来的基础上根据用户要求变更的功能点，然后公司上下开了个小会讨论如何实现，最后决定让小杨进行编码，我进行测试case的设计和代码测试，一切安排就绪。代码的编写过程中确实也碰到了困难，但是两个人一起讨论，最后加班赶出来，也经过确认没问题了。下班时，已是晚上九点。

第二天便进行代码的走查，前后花了半个小时，对新做的代码进行了讨论审查，并未对以前版本的代码进行检查（因为大家一致认为，以前的代码是OK的，并且这次变更的东西跟以前的代码不会有冲突）。完了我开始做代码测试，结果问题B产生了。

产生的问题是，以前的代码里有错误的逻辑直接拿过来复用，因为时间关系，小杨并没有逐行代码进行分析，而在代码走查的过程，大家也过于相信就版本的代码，认为其不存在逻辑问题。于是，问题就出现了。

究其原因，这次bug发生的最主要原因是，大家都把注意力集中在需要变更的需求上，而忽略了其对其他模块的影响，或者上层调用的接口是否一致问题，过于相信前人留下的代码，审查过程也是被代码走查主导人带入误区，盲目地认为只需要审查变更到的模块。

没有调查就没有发言权，很多时候，人的认识能力存在很多缺口很多误区，在项目deadline之前，项目组成员可能因为高度的精神紧张和压力而忽略了其他事情，转而专注到更为重要的事情上去，不是说其他的事情不重要，而是优先级2的事项很有可能就对优先级1产生影响。过于自信，往往是出现bug的重要原因。