代码复查.doc

Forpersonaluseonlyinstudyandresearch;mercialuse膂代码复查蚁代码刚刚完成时,是寻找问题的最佳时机。如果放任不管,它也不会变得更好。罿蒆代码复查和缺陷移除袃要寻找深藏不露的程序bug,正式地进行代码检查,其效果是任何已知形式测试的两倍,而且是移除80%缺陷的唯一已知方法。蒈——CapersJones的《估算软件成本》[Jon98]肇羅正如CapersJones指出的,代码复查或许是找到并解决问题的最佳方式。然而,有时很难说服管理层和开发人员使用它来完成开发工作。薃葿管理层担心进行代码复查所耗费的时间。他们不希望团队停止编码,而去参加长时间的代码复查会议。开发人员对代码复查感到担心,允许别人看他们的代码,会让他们有受威胁的感觉。这影响了他们的自尊心。他们担心在情感上受到打击。膆莅作者参与过的项目中,只要实施了代码复查,其成果都是非常显著的。莄Venkat最近参与了一个日程安排非常紧凑的项目,团队不少成员都是没有多少经验的开发者。通过严格的代码复查过程,他们可以提交质量极高而且稳定的代码。当开发人员完成某项任务的编码和测试后,在签入源代码控制系统之前,会有另一名开发人员对代码做彻底的复查。薁这个过程修复了很多问题。噢,代码复查不只针对初级开发者编写的代码——团队中每个开发人员的代码都应该进行复查,无论其经验丰富与否。薈螄那该如何进行代码复查呢?可以从下面这些不同的基本方式中进行选择。肄莈q通宵复查。可以将整个团队召集在一起,预定好美食,每个月进行一次“恐怖的代码复查之夜”。但这可能不是进行代码复查最有效的方式(而且听起来也不太敏捷)。大规模团队的复查会议很容易陷入无休止的讨论之中。大范围的复查不仅没有必要,而且有可能对整个流程造成损害。我们不建议这种方式。蚇q捡拾游戏。当某些代码编写完成、通过编译、完成测试,并已经准备签入时,其他开发人员就可以“捡拾”起这些代码开始复查。类似的“提交复查”是一种快速而非正式的方式,保证代码在提交之前是可以被接受的。为了消除行为上的惯性,要在开发人员之间进行轮换。比如,如果Joey的代码上次是由Jane复查的,这次不妨让Mark来复查。这是一种很有效的技术。膃q结对编程。在极限编程中,不存在一个人独立进行编码的情况。编程总是成对进行的:一个人在键盘旁边(担任司机的角色),另一个人坐在后面担任导航员。他们会不时变换角色。有第二双眼睛在旁边盯着,就像是在进行持续的代码复查活动,也就不必安排单独的特定复查时间了。袄荿聿q在代码复查中要看什么呢?你可能会制订出要检查的一些特定问题列表(所有的异常处理程序不允许空,所有的数据库调用都要在包的事务中进行,等等),不过这里是一个可供启动的最基本的检查列表。袇q代码能否被读懂和理解?莁q是否有任何明显的错误?蒁q代码是否会对应用的其他部分产生不良影响?***q是否存在重复的代码(在复查的这部分代码中,或是在系统的其他部分代码)?莆q是否存在可以改进或重构的部分?肁芈此外,还可以考虑使用诸如SimilarityAnalyzer或Jester这样的代码分析工具。如果这些工具产生的静态分析结果对项目有帮助,就把它们集成到持续构建中去吧。芆螅复查所有的代码。对于提升代码质量和降低错误率来说,代码复查是无价之宝。如果以正确的方式进行,复查可以产生非常实用而高效