第4章 同行评审

在IBM、微软等很多公司都有一个很好的实践，那就是代码复审。这种代码审查的过程，不是将代码发给某一个人或某几个人去看，而是强调程序员自己定期走上台，向其他人讲解自己源程序的活动。因为要向大家讲解自己的程序，程序员会极其重视自己的工作进度、代码质量，在写代码时，就时刻想着——可能随时会被选中去做代码复审，所以会非常认真地对待每一行代码。

公司为某省交通厅开发并实施了一套多层级公文交换系统。在平稳运行了3个月之后，出现了经常性地死机、公文流转串件现象。

重新组织大规模测试，将近10天时间，仍没有很好地定位错误。

“王哥，有时间吗？耽误您几分钟。这段代码有点问题，始终搞不定，您能帮我看下吗？”

“好的，是什么问题？”

“公文流转系统里经常串件，在正常情况下，发给王处长的文件跑到高局长那里去了。”

“咱们看看啊”

……

“这段代码没有什么大问题，可能是使用了这个全局变量的事，通常它是个捣蛋鬼。”

小张仔细检查了一下自己的代码，的确，轻易地使用全局变量，导致了这样一个很严重的问题。

下面一组数据是软件工程中常用到的：

AT&T的贝尔实验室在其开发中引入审查后的成功案例：生产率提高了14%，质量提高了10倍。有一个大型电力交换系统，发现错误的成本降低了10倍，在发现错误方面，审查的成效是测试的20倍。TRW对一个大型软件进行了研究，发现2019个由用户发现的错误导致代码变更。

分析结果表明，在这些错误中，通过代码审查可以发现62.7%，通过设计审查可以发现57.7%。

本书中研究的同行评审，定义为“由软件工作产品生产者的同行遵循已定义的规程对产品进行的技术评审”。其目的是为了及早和高效地从软件工作产品中识别并消除缺陷，让软件变得更易读和维护，同时减少最终泄漏到产品发布时的缺陷。主要工作第一是发现工作产品中的具体错误，第二是通过对这些错误的分类和统计，发现共同的错误类型和将来避免这类错误的方法，提供今后对所发现的同类错误进行控制的数据。通过对开发过程中的反馈和从错误中汲取教训，避免今后类似的缺陷和错误发生。

4.1 同行评审与测试的关系

发现缺陷的手段为什么要引入同行评审而不是继续完全使用测试呢？

有些工作产品在早期阶段就可以进行同行评审去发现缺陷，但无法对其进行测试；即使到了编码阶段，测试活动也不能发现某些特定类型的缺陷（例如违反编程规范）。

从图4-1（开发各阶段缺陷放大图）可以看出，随着开发的不断开展，缺陷不断泄漏和放大，最终形成的产品是一个灰色的距离用户真正需求很远的一个“东西”。这就需要在开发的过程中不断进行同行评审，减少泄漏到下一个阶段的缺陷。

成功的同行评审是提高质量和生产率的重要因素，不管人们喜欢与否，审查过程会迫使每个人在一种开放式的环境中工作。一旦人们懂得了他们的工作都要接受同行评审，他们就会越早地将他们的工作公之于众，以待监督。在同级评审上的投入把组织的一些质量成本从昂贵的测试以及后期的大规模返工转变为早期的缺陷发现。更重要的是，工作产品的作者学到了如何将工作做得更好，从而避免了缺陷。

固然同行评审的准备、活动和跟踪需要花费一定的时间和工作量，但这些可以在测试中节省更多。从经济角度考虑，许多缺陷是在早期阶段注入的，越早消除缺陷就越能降低开发成本。据统计，对于保存精确记录的大系统，一套完整的同行评审体系能够使项目在每个测试阶段出现的错误减少了90%。这样一来，即使在综合考虑了同行评审活动成本的情况下，同行评审活动也会使测试成本下降50%～80%。同时，通过同行评审，开发人员能够及时地得到专家的帮助和指导，加深对工作成果的理解，更好地预防缺陷，在一定程度上提高了开发生产率。再者，消除工作成果的缺陷，可以提高产品质量，提高客户满意度。

图4-1开发各阶段缺陷放大图

总之，同行评审有助于“提高质量、提高生产率、降低成本”。

但是要注意，同行评审不可能代替测试，正如测试不可能替代同行评审一样。

那么，工作产品通过了什么样的评审才算合格呢？同行评审本身的要求有没有在质量目标里？评审的工作量和参加人员的资格、评审时间是否有要求呢?

4.2 同行评审的种类和对象

同行评审活动的关注点应该是工作产品中的缺陷，而不应该是工作产品的作者或者生产者，管理者也不应使用同行评审的结果去评价个人的行为。

同行评审的分类有很多种，自从IBM的Fagan发明了同行评审之后，软件行业提出了很多同行评审模型，比较著名的有IEEE1028评审、微软的技术评审、GillGraham审查、VanEmden审查、Yourdon结构化走查等。

4.2.1 同行评审的种类

本书中按照CMMI模型的提法，将同行评审分为3 类。

（1）正式评审（Inspection），通常是由经过同行评审培训的项目经理或PPQA主持，规模在 3～7人之间为宜，一般在完成了一个工作产品后对其进行的评审。正式评审的目的在于定位并除去工作产品中的缺陷。

（2）技术审查（TechnicalReviews），或称内部评审，通常由技术负责人或项目经理召集，三人以上参加。技术审查一般是在工作产品的中期进行或完成了某部分独立的工作产品时进行，也可在书写草案遇到问题时就其中专门的一两项问题讨论和审查。也可以是检查工作产品与规程、模板、计划、标准的符合性或者变更是否被正确地执行。技术审查的目的在于通过对开发人员的工作产品的技术审查，提出改进意见。

（3）走查（Walkthrough），又叫代码走查或代码走读，审查的范围根据需求的优先级通常由管理人员来确定，主要是静态质量分析和编程规则检查。通常是小型讨论会，一般是在工作产品形成的早期进行，作者有一定的想法时，希望从中获得一些帮助或补充一些想法。当然也可以在编制工作产品的任何阶段进行，两三个人参加，由作者主持，主要是评估和提高工作产品的质量或教育参加者。

其中，“正式评审”是正式的，“技术审查”和“走查”是常用的非正式同行评审方法。

4.2.2同行评审的对象

同行评审的对象包括所有软件开发的中间和最终工作产品，例如包括：

（1）产品需求规格说明书；

（2）用户界面规范及设计；

（3）架构设计、概要设计、详细设计及模型；

（4）源代码；

（5）测试计划、设计、用例及步骤；

（6）项目计划，包括开发计划、配置管理计划和质量保证计划等。

所有这些会涉及的评审内容，应该在编制的项目计划或者小的开发计划中体现，不应该也不能是临时性的安排。

4.3 同行评审过程

根据同行评审的重要程度，正式评审、技术审查和走查三种形式的流程和成果物的使用力度不尽相同，但其主要的步骤和内容大体一致，参见如图4-2所示的同行评审流程图。

图4-2 同行评审流程图

4.3.1 正式评审流程

正式评审包括下述6个基本步骤。

（1）预备：为保证评审的质量，可以先进行一个预备会议。

会议上，由作者花几分钟的时间向评审组概要介绍评审材料，例如讲解一下本工作产品的目标是什么，其他相关的实现细节、开发标准等。应该允许甚至鼓励评审组成员动手查看工作产品，或者查看开发过程中所用到的检查单等。这个讲解的过程从某种角度上来说，也保证了作者提交工作产品的质量。会议结束时把文档分发给每位与会者，下发的材料应该控制在2小时之内审核完成为宜。这些文档可以包括：

• 要审查的工作产品；
• 参考文档；
• 工作产品评审检查表；
• 工作产品审阅情况记录表。

（2）审查：在预备会和正式评审会之间，评审小组成员会对工作产品进行彻底检查，并依据相关标准和准则评审工作产品，记录发现的缺陷、问题种类与严重程度、所用的时间等。

（3）评审：在预定的正式评审时间内（会议时间建议控制在2小时），评审小组成员以会议形式聚在一起，依次对产品进行检查。每个评审员花一定的时间（一般为十几分钟）指出问题，并和作者确定问题和定义问题的严重程度。注意，评审过程中是发现错误，而不是现场改正它们。

会议中，记录员详细记录每一个已达成共识的缺陷，包括缺陷的位置、简短描述缺陷、缺陷类别、该缺陷的发现者等。未达成共识的缺陷也将记录下来，加入“待处理”或者TBD标识，评审主持人将指派作者和评审员在会后处理评审会议中未能解决的问题。

（4）书写评审报告：评审主持人根据记录员的记录和自己的总结，在一天内写出评审报告，内容包括：

• 根据评审专家个人的输入创建总的问题清单；
• 加入会议中发现的问题；
• 剔除经确认属于重复或者无效的问题；
• 共同确定需要修改的问题及修改的程度。

（5）返工：作者根据评审报告的决议，负责解决确定的所有缺陷和问题。

（6）跟踪：评审组长必须确保所提出的每个问题都得到了圆满解决。必须仔细检查对文档的每个修正，以确保没有注入新的错误。

4.3.2 技术审查流程

技术审查通常包括下述3个基本步骤。

（1）准备：评审组长（通常是项目经理）要求项目组成员提供需要考虑的特定问题并分发评审材料。评审组长确定评审重点：

• 需要注意的特定问题；
• 需要满足的特殊标准或规格说明；
• 需要审查的接口或依赖关系。

（2）评审：评审人各自审查评审材料，目的是发现错误，而不是改正它们（通常每次评审会不超过1小时）。评审组组长应在一天内写出评审报告。评审会议内容包括：

• 汇总个人发现的问题；
• 加入会议中发现的问题。

（3）跟踪：作者负责解决评审报告中的所有错误及问题。评审组长检查所提出的每个问题都得到了解决。组长起草评审发现报告：

• 问题或弱项清单；
• 小组对如何解决这些问题或弱项清单的建议；
• 行动事项。

4.3.3 走查流程

走查对形式的要求更为简单，主要有下述两种方式。

（1）参与者驱动法：参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。作者必须回答每个质疑，要么承认确实有错误，要么对质疑做出解释。

（2）文档驱动法：作者向评审人仔细解释文档（或代码）。在此过程中，可以将评审的内容（如关键代码、架构图、业务逻辑图等）用投影仪投射到屏幕上，作者对工作产品进行讲解，评审人不时针对事先准备好的问题或解释过程中发现的问题提出质疑。它比参与者驱动法可能更有效，往往能检查出更多错误。经验表明，使用文档驱动法时许多错误是由文档讲解者自己发现的。

在走查过程中，每个评审人都要记录错误或建议，会后要整理会议记录，作为走查报告。工作产品的作者可以根据自己的思路对走查报告质疑。

注：对代码的同行评审其实就是代码走查，可以使用投影仪打出关键代码位置与参与人员一起读，也可以几个开发人员一起进行交叉走查。选定的进行代码走查的范围根据需求的优先级来具体确定。

4.4 同行评审方式的选择

对于同一个工作产品，根据所处于的阶段可以使用不同的评审方式。如对于工作产品刚刚勾画、起草时，可以采用走查方式；对于完成了某一个单独的章节，可以采用技术审查方式；待整个产品完成，使用正式评审全面考察。

4.4.1 三种同行评审方式的比较

对不同的工作产品，可以根据表4-1建议结合项目情况进行调整和裁剪。

表4-1 三种同行评审方式的比较

4.4.2 同行评审的结果

同行评审的结果通常有3种：

（1）正常：评审专家做好了评审准备，会议正常，结果明确，不需要再次评审；

（2）延期：30%以上评审专家没有做好准备，会议无法正常进行，需要确定再次评审时间；

（3）取消：在初审阶段就发现很多问题，需要作者进行修正，然后再进行第二次同行评审。