捉虫记

看到这个题目，大家可不要误会，我所说的虫子并不是法布尔笔下妙趣横生的昆虫。恰恰相反，我要谈的虫子总是让那些与之打交道的人心烦意乱。没错，它们就是软件中的bug。

除了设计与开发，软件开发人员最常做的工作就是修改bug了。那些刚接触项目新手，往往被安排从修改一些简单的bug开始做起，逐渐熟悉环境和系统，在对项目和流程熟悉之后再进行较深入的bug修改以及开发工作。在有些IT公司里有专门的系统管理bug（比如bugzilla），bug一般被称为问题单（或者一个ticket），可以按照优先级进行分类，也可以根据其严重程度分类。比较常见的是根据其严重程度分为提示缺陷、一般缺陷、严重缺陷、致命缺陷。对bug分类便于对bug进行操作和管理，问题解决人员可以根据bug的类别选择最需要修改的bug优先处理。

除错的第一步是找出问题必现的条件，这一环节往往由测试人员进行。在测试人员提交问题单时，会详细记录该问题出现的条件与环境。找到必现的条件也就知道程序的流程，也就能顺藤摸瓜找到问题出现的大体位置。接下来的工作就是根据问题的表现出发，逆向思考，查看代码，发现原因。我们可以借助编程语言或者工具来除错，比如在代码中添加打印语句，或者跟踪堆栈轨迹中的信息等。如果问题难以浮现，我们需要尽量使之可靠地浮现，比如构造某些输入或者设置参数等；我们还可以使用分而治之的策略，比如采用二分法对代码进行测试，排除掉与问题无关的代码，缩小出错的代码范围。

除错也是一个熟能生巧的过程，新手们刚接手时经常会一筹莫展，而老手们则会根据表面的数据和积累的经验抓住问题本质，一针见血地找出错误所在。幸运的是，我们生活在一个信息资源极其丰富的时代，前辈们留下了许多关于除错的技巧与方法。我们可以参考《程序设计实践》的第5章、《程序员修炼之道》的第3章以及《代码大全》的第23章等。虽然有这些资料可以参考，但是要成为真正修改问题的高手，需要在工作中不断积累、持续学习。

除错过程中肯定需要修改现有的代码，在修改代码时，需要标明对此处代码修改的各种信息，比如修改原因、修改人、修改时间等。这一般就有两种实现方式，一种是直接在修改的地方标明，另一种是通过代码版本控制工具（比如CVS）在更新代码的时候写明修改代码的各种信息，这种信息通常会加入到代码文件的头部。这两种实现方式都有自己的优缺点，第一种方式比较直白简洁，缺点是过多的修改信息会破坏代码的整齐性，“弄脏”原有的代码。第二种方法不会在代码中加入过多的信息，保持了代码原有的风格，缺点是不如第一种方式简单方便，如果新版本的代码对原有的代码作了修改，我们不能从修改的地方直接获得修改的信息。

开发人员在除错结束后，将问题修改的记录和修改后的软件版本交给开发经理，由开发经理亲自或者安排其他开发人员审核后正式转给测试部门进行回归测试，测试人员测试通过后结束此问题的修改流程，将问题单处理流程入库备案。这样从问题的发现、到问题的修改、到最后测试人员的回归测试通过，把整个问题处理过程作了详尽的描述和备份。保存问题单的问题单库，不仅可以用于QA人员对项目质量进行评估和审计，也可以作为一笔宝贵的财富提供给开发人员进行学习和参考，从中我们可以看到常出错的地方以及各种解决问题的方法与技巧。因此，问题单决不应该仅仅作为一个流程存在，更应该作为一个问题记录文档而存在，从测试人员到开发人员都应该对自己针对该问题所做的工作进行详细记录，不能因为此问题已经解决，就想当然认为最主要的工作已经完成，而忽视了对问题进行详细记录，草草地敷衍搪塞过去。

高质量的软件离不开高质量的软件开发过程，软件系统的质量与开发过程中的每一环节、参与的每个人员都息息相关。问题发现的越早，对后续的影响越小，修复成本也就越小。如果bug到了用户使用软件的时候才出现，造成的后果是难以估量和无法挽回的。对于开发人员来说，要想编制高质量的代码，减少日后修改问题的工作量与成本，在实现代码时必须要严格遵守编码规范。很多bug往往是由于编码时的粗心造成的，比如使用指针时没有判断是否为空，申请堆内存而又在出现异常的处理分支的返回之前忘记释放内存等等。失之毫厘，谬以千里，这些看似很简单的小毛病到了后期往往就会表现为时而出现、时而消失，让人捉摸不定的大问题。一个优秀的软件开发人员会以严格的编码规范指导自己，在容易出错的地方，比如全局变量的初始化、操作指针、内存的申请与释放等会倍加谨慎。在开发过程中形成整齐统一的风格，也会大大降低以后维护代码的成本，毕竟大多数程序大部分时间还是给开发人员看的。正所谓“前人栽树，后人乘凉”就是这个道理。还有一种比较有效的方式是代码评审，项目经理招集一些有经验的开发人员召开评审会议，对新开发的代码进行评审。代码作者讲解代码的流程和功能，评审人员对代码发表见解。项目经理还要安排专门人员对评审会议进行记录。评审是软件开发过程中一种有效的软件质量保证活动，它不仅仅局限于代码评审，也包括对各种文档和产品进行评审，其形式也是灵活多样。关于软件质量和技术评审，可以参考《软件工程-实践者的研究方法》中第8章内容，这里就不详细说明了。

在这里我讨论了关于bug的一些看法和认识，这些也算是我实习工作的一个小小的总结。在三个多月的时间里我修改了项目里近百个bug，接到问题单时的彷徨与迷茫、修改问题时的思索与钻研、修改成功时的喜悦与兴奋至今都历历在目、难以忘怀，它作为我职业生涯的起步给我留下了一笔宝贵的经历。如果你此时正被bug搅得焦头烂额，不妨听从Kernighan和Pike在《程序设计实践》一书中提供的建议，休息一下，整理头绪，在电脑旁放一个玩具熊，然后开始对他讲述你的代码，没准讲上一会就豁然开朗了。