在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发明了同行评审之后，软件行业提出了很多同行评审模型，比较著名的有IEEE 1028评审、微软的技术评审、Gill Graham审查、Van Emden审查、Yourdon结构化走查等。

4.2.1  同行评审的种类

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

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

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

（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）取消：在初审阶段就发现很多问题，需要作者进行修正，然后再进行第二次同行评审。

4.4.3  正式评审的特征

相对于走查和技术评审，正式评审具有一些明显的特征。

（1）评审以一种正式的形式进行，如有正式的、事先定义好的有关职责的各种角色，并遵循组织规定的标准流程。

（2）对于任何工作产品的评审，都会组建与之对应的专门评审组，包括作者、主持人、记录员以及评审员若干。评审组成员也可以包括项目经理、PPQA，但是不能有作者的直接领导或者管理者。

（3）评审小组先召开一个预备会议，作者会针对工作产品向大家做一个总体的介绍，例如讲解一下本工作产品的目标是什么，其他相关的实现细节、开发标准等。应该允许甚至鼓励评审组成员动手查看工作产品，或者查看开发过程中所用到的检查单等。

（4）评审小组的主持人负责确定什么时间开始真正的评审会议，在预备会和正式评审会之间，评审小组成员会对工作产品进行彻底检查，并依据相关标准和准则评审工作产品。

（5）在预定时间，评审小组成员以会议形式聚在一起，依次对产品进行检查，主持人负责对整个会议的进展进行控制，而记录员则负责记录下整个过程。

（6）在工作产品中发现的每一个缺陷都会被认真记录下来，并被适当分类。

（7）会议结束后，负责人需要分析有关缺陷，找出产生此缺陷的原因并加以修正。

（8）主持人应确保所有的缺陷都会得到解决和修正。如果过程需要加以变更的话，应将相关问题移交相关的过程质量组。

正式评审的正规性特征还体现在按发生频率和严重程度，仔细划分缺陷的类型，并且把这些信息运用到缺陷预防阶段以及未来产品的同行评审过程中。

4.4.4  工作产品的同行评审方式

对开发过程中产生的主要工作产品所采用的同行评审方式以及参加评审人员，可以参考表4-2确定。

表4-2  常见工作产品的同行评审方式和参加评审人员

4.5  迭代生命周期的审查

审查是提高瀑布模型项目质量的好方法。但对于迭代项目来说，如何在短的周期来做该工作呢？需要考虑迭代开发生命周期中审查的角色。

在瀑布型过程中，审查对成功是至关重要的，因为团队不看重较早开发的代码，也就是说，他们不会回到前面的"阶段"。同时，由于瀑布周期时段很长，以至于到下游阶段发现错误时，原作者常常已经帮不上忙，即使可以，他们也已经忘记了工作的内容。使用瀑布方法时，审查是对抗糟糕质量的唯一安全措施。

相反，迭代开发周期短（平均3～9周），每个团队成员都是确保迭代成功的关键，即当下游人员发现错误时，这些成员不仅可用，而且他们已经准备好并期望在生命周期中尽早开始修复工作。

通常在进行工作产品审查时，大家倾向于无论看到的问题对于迭代成功的重要性如何，都会猛扑向任何发现的错误（甚至是极其微小、无足轻重的）。尽管审查似乎要求成员尽量争取完美，然而在短的迭代周期中，更应该关注的是完成工作。一定要记住迭代方法的原则是"让迭代自己证明自己"，允许质量可疑的事情进行。当实际使用时，我们将认识到它是否足够好。

无论何种开发生命周期，审查中的主要反馈来自下游的使用者，因为他们将不得不使用系统。对于迭代开发过程，唯一不同的是与其在交付到下一道"工序"前审查工作产品，不如把工作产品实际地立即投入使用，在实践中进行检验，这是它最重要的改进。

那么这意味着在迭代生命周期中不应该有任何审查吗？不是的，但确实进行的次数比大部分项目团队少得多，特别是如果团队一开始就采用瀑布型的方法。如果真的接受迭代方法，那么审查的数量应该被自动地减少。举例来说，如果迭代项目的生命周期是六周，则应该考虑进行多少审查工作，而不影响完成迭代的工作。

在迭代开发中，创建计划证明迭代过程的正确性是非常必要的。对于重视审查的项目团队，在初始阶段还有一个额外的步骤。就是要将需审查的每个工作产品映射到迭代中。假设限制每个迭代过程中最多三个工作产品，那么对于六周的迭代过程，三个审查会显得很繁重，唯一的办法就是减少审查的数量，因而需要为审查计划提供许多提示，并且确保正确的人参与。，避免落入频繁审查的圈套。

4.6  同行评审的注意事项

为了有效地提高同行评审过程的质量，经常需要对过程数据进行度量（关于软件度量的专题，见本书第7章中相关内容），作为进一步提高过程的依据。

公司有一次组织产品需求的同行评审，会议定在5号上午9：00～11：00进行。开始之前采用邮件形式通知了参会人员，并没有把评审材料发给大家。

会议邀请了两位技术负责人，其他人员都是对技术不是很了解，且不了解评审过程与意义的管理人员，没有安排专门的人员做会议记录。

会议上，大多数管理人员按照个人的喜好与想法来评价软件的优缺点，并且对此软件的开发人员进行评论，提出了偏离评审会议主题的各种意见，使得原本安排2个小时的评审会议时间延长到了4个小时。软件中存在的问题给予了很少的关注。

主持人宣布了会议的主题。作者开始简述自己的产品需求，接下来评审提出自己的意见。

评审员小李说："关于查询结果排序：查询后的表格应该是动态的，现在FW是固定的，这个需要改进。"

其他人也参与该问题的讨论。"如果继续使用FW提供排序功能，那么需要FW项目组进行修改，FW的负责人小张说说是否可行，打算怎么修改。"

小张开始提出自己的想法以及如何改进，几个同行也都说出自己的想法，有时会遇到不统一的现象，开始解释和说明，等这个问题讨论完了，才发现时间已经过去40分钟。大家继续后边的问题，2个小时过去后，需求评审只进行了一半，会议以没有评审结果而宣告结束，只能下次继续进行，会议中没有任何表格填写。

通过上边的例子，我们看到在评审中发生了5个违反规则的做法：

（1）采用邮件方式通知大家，没有专门通知到个人。

（2）没有预先下发被评审的工作产品和检查单。

（3）会议的焦点不是在确定问题上，而是转到了如何解决问题。针对问题的解决，讨论很多，同行评审会议最主要的是找到和确定哪些是问题，至于如何解决问题，可以在评审会后相关人员继续讨论。

（4）主持人没有经验，没有很好地主持和控制会场局面，当遇到会议跑题的时候，一定要记住会议主题，将讨论的焦点带回来，不然容易越走越远。

（5）没有作缺陷的记录和发现工作量的记录。

同行评审时，需要注意以下几点事项。

4.6.1  同行评审遵循的原则

同行评审有所谓的"123准则"：同行评审准备时间大于开会时间，同行评审期间发现的缺陷数量应该是同行评审准备期间发现的缺陷数量2倍以上，同行评审发现缺陷的效率是测试发现缺陷的3倍。

（1）同行评审需要管理层的支持，如果没有，即使是目标明确的开发组成员也会抵制进行评审。管理层的支持包括建立评审策略和目标，提供资源、时间、培训和激励，并遵守评审小组的决定等。

（2）同行评审是结构化的过程，涉及许多参与人员的角色，在评审专家的选择性上，一定要注意其中的互补性。经验表明，同行评审的参加人员在他相关的技术领域与方向发现缺陷的效率较高，需要为参加人员分配职责，会议参加人员要从不同的技术角度发现缺陷。

（3）对于每种类型的同行评审，应制定通用的工作产品评审检查表，必要时可以进行裁剪以适应特定项目的要求。工作产品评审检查表应涵盖审查计划、准备、实施、结束和报告准则。

（4）评审开始前，评审人应提前准备好自己所关注和将要提出的问题。

（5）评审的重点在于发现问题，而非解决问题，再加上认真细致的准备工作，可以最大程度避免在评审中浪费时间。

（6）对于技术人员工作的审查，应由技术人员进行，管理人员不要参与。但应将评审结果和解决所发现问题的日期通知管理人员。

（7）评审的过程是对事不对人的，例如用"这个假设是错误的"来表述，而不是尖刻地说"你的假设根本不对"。

（8）成功的审查要求所有参与人员精力高度集中，可能会使参与人员十分疲惫。因此，每个审查阶段最好不要超过2小时。对每个人来说，一天最好只参加一个阶段审查。

（9）将评审数据输入到组织度量库中，用于监测评审效果，并管理和跟踪产品质量。相关的度量数据示例有：

在全过程使用同行评审，要占10%的开发工作量；

每20页叙述性文档，需要40人时；

每12页概要设计，需要30人时；

每1000行代码，需要55人时；

使用一段时间后，评价一个项目或一个组织的审查结果需要1人月。

4.6.2  同行评审关注的问题

（1）有同行评审计划，并在每次评审前进行详细安排，如邀请合格的专家参加评审，邀请被评审产品的作者参加评审，明确定义应该评审哪些内容，评审人员要有明确的分工。

（2）对同行评审中发现的缺陷进行详细记录，如缺陷所属模块、缺陷严重程度、解决期限等，并安排相关人员对缺陷进行跟踪直至解决。

（3）对评审的过程进行度量，如评审准备时间和评审时间以及这两个时间之比，评审准备期间发现的缺陷数和评审期间发现的缺陷数以及这两个数值之比，评审工作产品的规模和评审效率等。

（4）为保证同行评审的独立性、公正性，需要有经验的组外同行参加，需要对评审人员的能力定期衡量，及时更新保证其有效。

（5）对类似的软件进行评审和测试。有句话说得很好"你想不到的你的敌人会告诉你"，通过对竞争对手产品研究，可以很好地提高工作效率。

4.6.3  同行评审通过的准则

同行评审通过需要满足以下的准则。

1．最小准则

（1）工作产品已经返工和确认；

（2）主持人已经发布审查报告。

2．基于组织的度量元或早期的审查，可以为这类工作产品设置出口准则

（1）剩余主要缺陷数的估计是否在限定范围内；

（2）剩余次要缺陷数的估计是否在限定范围内；

（3）变更数量在限制范围内（例如：IBM一个部门的指南规定，变更代码应少于评审代码的5%。Ebenau，1994，p.58）。

4.6.4  同行评审的经验共享

只有软件的生产者是唯一可能做到生产出无缺陷程序的人，其他任何人都对此无能为力。

（1）所有的缺陷最终都应追溯到需求，因为最严重的错误是"导致程序无法满足需求"的错误。

（2）软件开发人员和管理人员首先应该尽早地和不断地进行各种软件质量保证活动（如需求和设计阶段同行评审和走查等）。

（3）软件开发人员应避免检查自己的程序，利用同行评审的方式对代码进行审查（因为自己检查容易依照原有的程序设计思路进行，往往查不出问题）。

（4）在进行各种分析和修复工作中，要充分注意修复工作所产生的影响效果和波及效果。

（5）统计表明大约有60%的错误是在设计阶段之前注入的，并且修正一个软件错误所需的费用将随着软件生存期的进展而上升。错误发现得越晚，修复它的费用就越高，而且呈指数增长的趋势（见附录中1:10:100公理）。

（6）程序中的大部分错误往往是在一小部分模块中发现的，遵循普遍适用的"二八定理"（即80%的错误往往是由20%的模块所造成的）。

（7）缺陷会掩盖或加重其他缺陷。也就是说，当一个程序有许多缺陷时，由于缺陷相互作用，使得发现和修复缺陷的过程更加复杂。这使得一些缺陷很难查找和修复。一个缺陷可能掩盖其他缺陷，使得这些被掩盖的缺陷难以发现，增加了它们逃过测试的可能性。

（8）遵照规范化的方法，仔细复查和测试每个小程序模块，这比让任何测试组在你的程序中发现缺陷的效果要好。也就是说，尽早地将缺陷排除掉。测试不能避免缺陷的发生，只能是一种补救。

4.6.5  文档审查重点

文档审查要对文档的完整性、一致性和正确性进行审查。

1．文档的完整性审查

（1）用人工审查的方法，验证所提交软件文档是否齐全；

（2）文档中是否包含对软件接收输入数据类型和边界值的描述或说明，包括最大值、最小值、键长、文件记录的最大长度、搜索准则最大值、最小样本尺寸；

（3）对不可能提供固定的边界值（例如，某些边界值依赖于应用类型或输入数据）的情况，是否说明极值；

（4）是否包含与保密信息有关的信息，应包括防止非法授权访问的措施说明。

2．文档的一致性审查

（1）用人工审查的方法，审查文档内容和术语的含义前后是否一致，有没有自相矛盾的地方；

（2）检查文档与程序的一致性；

（3）检查书面文档与联机帮助文档的一致性。

3．文档的正确性审查

（1）用人工审查的方法，审查文档内容是否正确和准确；

（2）是否有错别字；

（3）是否有二义性的定义、术语或内容。

4.7  同行评审的度量

同行评审和测试被业界认为是最主要的有效发现缺陷的手段（二者所发现的缺陷可以占到发现的缺陷总数80%～90%，因此对二者的度量分析工作将更加重要。具体的度量过程、方法、度量元，会在本书中的"软件度量"相关章节中详细描述。本节仅就同行评审中应该注意搜集的数据进行一下说明。

为了有效地提高同行评审过程的质量，经常需要对过程数据进行度量，通过度量分析可以看到同行评审效率怎样，测试效果如何，作为进一步提高过程的依据，不断改进的过程，提高产品质量。

某款软件产品的设计文档有20页，按以往的估计，评审中将会有100个缺陷。但是，这次评审实际上仅仅发现了60个，原因何在？可以使用鱼骨图、因果图对发现内容进行分析，是具体的同行评审过程执行得不好？还是经验不足？抑或是同行评审过程规定得有缺陷？是否规定了先看过再评审？还是产品的设计文档质量比较高？

这些都需要考虑一下。

4.7.1  常用度量元

对同行评审应进行度量，如需要获得评审准备的时间和评审时间以及这两个时间之比，评审准备期间发现的缺陷数和评审期间发现的缺陷数以及这两个数值之比，评审工作产品的规模和评审效率等主要内容。具体的度量数据应该包括：

（1）主要问题的个数/同行评审投入的总工作量。这些工作量一般用人时来表示，其中包括准备、发现以及更正等所有环节和方面的工作量。

（2）一般在缺陷会议结束时估计，然后在同行评审结束时得到实际值。

（3）我们的效率是否正常/工作产品是否正常。

（4）评审准备时发现缺陷数和评审时发现缺陷数及其比率。

（5）记录问题的个数/评审会议所用的时间，一般用个数/分钟表示。

（6）评审会议结束后得到问题记录的速率。

（7）反映评审会议的控制是否得当。

（8）评审专家的准备是否充分。

（9）主要问题与所有记录项的比率。

（10）主要问题个数/所有记录项个数。

（11）判断角色分配是否合理。

（12）缺陷密度。

（13）同行评审总缺陷数和有效缺陷数及其比率。

（14）评审文档页数（代码行数）。

（15）缺陷移除率和缺陷泄漏率。

（16）准备时间和评审时间（小时）及其比率。

（17）同行评审的缺陷打开和关闭的情况统计。

（18）同行评审的效率、评审速率的度量。

（19）同行评审的覆盖率。

4.7.2  同行评审的质量准则

根据Watte Humphrey于1998年提出的经验数据，设计阶段同行评审工作量应该占到该阶段工作量1/3或以上，代码评审工作量也要占到编码和单元测试阶段的工作量1/3以上。如果它们都只占到15%，此时同行评审的质量系数仅仅是0.5。

业界的通用准则如下：

（1）设计同行评审工作量应占设计阶段总工作量的1/3以上，其质量准则为：设计文档同行评审应该至少发现3个缺陷/页。经评审修改后，缺陷清除率1级100%，2级100%，3级80%以上，残留缺陷密度控制在0.5个/页以下。

（2）代码同行评审工作量应占实现阶段总工作量的1/3以上。

（3）同行评审准备过程发现的缺陷数应该是同行评审会上发现的缺陷数的2倍以上。

4.7.3  建议的同行评审效率

如果在软件开发全过程中使用同行评审及审查，它们的总工作量要占10%的开发工作量。

1．同行评审准备效率

（1）需求250行（5页）/小时；

（2）概要设计200行（4页）/小时；

（3）详细设计150行（3页）/小时；

（4）源码150行（无注释）/小时。

2．同行评审会议效率

（1）每20页叙述性文档，需要40人时；

（2）每12页概要设计，需要30人时；

（3）每1000行代码，需要55人时。

审查的效率取决于以下因素：

（1）在准备和实施过程中所耗费的时间和工作量；

（2）实际的审查速度超过推荐的审查速度时，审查效率往往会降低；

（3）最佳的审查速度取决于所审查的产品类型与审查人员的技能和经验。

4.7.4  同行评审覆盖率

在有效的开发过程中，一般对同行评审有如下的覆盖率要求。

（1）对需求的同行评审覆盖率要求100%；

（2）对设计的同行评审覆盖率要求100%；

（3）对系统和验收测试用例的同行评审覆盖率要求100%；

（4）对代码的同行评审覆盖率要求不少于30%。

新编代码的关键部位和关键算法要进行100%的同行评审（此比例不能放松，每个分支的组合条件都要审查）。

非新编代码采取采样评审，采样比不少于25%。

4.8  评审常见问题

根据Humphrey的经验，审查不能发挥作用的原因大致如下：

（1）最大的问题是进度紧张而且管理重视不足，使得审查流于形式；

（2）实施审查的方法不当；

（3）准备不足；

（4）参与人员太多或者参与人员不能胜任，或者有管理人员参与；

（5）一次涵盖的内容太多；

（6）在记录会议中试图修复问题；

（7）记录会议拖沓冗长；

（8）对个人进行评价等。

同行评审常见问题总结如图4-3所示。

（点击查看大图）图4-3  同行评审常见问题

其中有些原因和解决方式在前面"同行评审遵循的原则"中已经讲到了，在本书的后续章节中也会述及。

4.8.1  文化问题

现象1：进度驱动而不是质量驱动

没有重视产品质量，造成评审的时间被一再挤压，特别是工作产品的预审时间。

现象2：管理层没有为评审明确期望的目标

管理者没有为评审提供有效的方针和环境，同时对于没有参加评审的人员或者不合格的评审没有任何说法或者措施。此时，可以请管理者发布管理方针，阐明审核目标；要求开发组成员遵守政策。

现象3：一些开发组成员拒绝评审其他人的工作或者合作

不理解软件开发是集体努力的结果，怕暴露自己的缺点或不足，怕评审过程得罪人。

要教育大家，所有工作人员作的努力可以帮助同事改进他们的产品，延长产品的生命周期，使产品的维护人员、公司及客户受益。参与评审的人员以及他们对于质量的态度最能决定评审的成功与否。其中最重要的是开发组成员自觉地希望同行来发现错误，而不是由用户最终发现。

现象4：人身攻击和讽刺很普遍，作者处于防卫状态

当组建评审小组时，要预防个人冲突，个人冲突将会降低评审的效率。如果有必要，将犯规者赶出评审小组或停止评审过程，并向过程管理者说明为什么要这样做。

安排一个关于如何在团体内进行有效沟通的辅导课程，要确保那些犯规者必须参加，并说明这是进修的培训而不是惩罚措施。

现象5：评审中收集的数据没有在其他任何地方使用

确保数据提供给同行评审主持人，并且将数据存储在知识库中。

采取措施让管理层、同级评审过程拥有者和同级评审协调者决定哪些数据是重要的，以及如何最好地提交数据。

提供适当的数据分析和报告工具。如果经过所有这些努力，数据仍然不能被使用，停止收集数据。

4.8.2  准备问题

评审的问题很大一部分出现在准备上，这不仅仅是说某个项目的评审准备，甚至可能是整个组织内部对评审工作没有制定相关的标准和规范，没有建立组织级过程。

现象1：在项目计划中没有列入大的评审工作

由于没有明确的组织过程遵循，造成评审计划草率、不合实际，或没有及时调整，或实施不力。

由于计划组织不充分，评审资源没有得到保证，资深技术人员或者评审人员忙于其他工作，没有投入足够的时间。

现象2：没有接受培训

此评审人员的选拔是很重要的。如果确实没有合适的人选，那么在评审准备阶段进行评审所需的知识和技能的培训是很有必要的。

评审员一般是领域专家而不是评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行培训。对评审员的培训也可以区分为简单培训与详细培训两种。简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中需要把握的基本原则及要注意的常见问题说清楚；详细培训需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。

对于主持人来说，掌握完整的审查原则和方法对他们来说是绝对必要的。培训不仅可以向他们传授基本技能，同时也有助于他们建立信心，来组织往往有争议的审查工作。

现象3：直到评审会议上评审人员才看文档，而没有提前阅读文档并提出大部分问题

造成这一现象的原因可能是评审人员事情太多，也可能是因为评审人员对会议有依赖心理，不愿意阅读文档，只希望到会议上听别人解说。不做准备而完全靠评审会议上的有限时间来进行评审是评审失败的主要原因。

现象4：文档质量太差

作者缺少自我检查，或因计划不合理，提交的文档是没有任何复查的"草稿"。一定要注意，正式评审中提交的文档应该是经过被评审人员自己充分检查过的文档，不能把查问题的责任完全推给评审人员。对于明显未达到要求的文档，需要退回修改后再提交评审。

判断作者在提交评审前是否试图完善了他们的产品。

在工作进行了一小部分后即进行预评审以纠正系统错误，及早提供改进的机会，以便作者能够保持适度的热情。

4.8.3  焦点问题

现象1：没有遵循2/8原则注意评审的重点

要评审的对象内容需要有侧重点，一般按照2/8原则确定主要内容进行评审，而不要泛泛地对整篇文章进行处理。

现象2：就某个文档而孤立地评审该文档，没有对照已有的成果和标准

需求和设计是软件开发项目的中间文档，前面会有一些约定输入，也可能会要求遵守相关标准。除非是对这些输入的内容已经了如指掌，可以敏感地发现互相之间的不一致性；否则一定要考虑仔细对照相关的输入。

就某个系统而评审该系统，没有考虑相关系统。当客户或企业已经开发了多个软件系统之后，系统之间的相关性必须是考虑的因素，这些相关性包括数据之间的关系、业务之间的关系、用户管理、系统管理的一致性，操作习惯和界面的关联性和软件复用等。

现象3：会议上过多地讨论问题如何改正

评审的目的主要在于定位问题，一旦正确地确认了问题，大多数都能很快找到解决方案，对于一时无法给出解决方案的问题可以在评审后研究讨论。

因此，一般的同行评审会建议如果在一个问题上超过3分钟，可以做出结论并到下一个问题；如果评审专家之间有不同意见，做出记录，得到结论并到下一个问题。

当评审专家讨论起解决方案时，主持人可以要求他们在会后讨论。

现象4：评审与评价混淆

评审的目的是指出具体问题以便改进，评价是给最终工作结果及人员工作绩效下结论。不能把这二者混为一谈，尤其是把评审结果作为评价个人能力的指标时，对评审活动的进一步开展很不利。

4.8.4  人员问题

为了保证评审的质量和效率，需要精心挑选评审员。

现象1：评审人员选择不合理

无论什么领域评审，都是同样的评审专家。首先，要保证不同类型的人员都要参与进来，否则很可能会漏掉很重要的需求。其次，在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审效率降低或者最终不切实际地修改了系统的范围。

现象2：评审人员搭配不合理

在选择评审人员时，遗漏了某些角度或层次的人员。一定要注意，和每个软件开发项目团队的人员搭配一样，评审人员的搭配也应该尽可能合理，考虑全面性和有效性。可以用上述评审角色层次结构与角度结构（可进一步完善）来发现选拔各个层次和角度的评审人员，建立公司级别的评审人员库，在需要评审的项目中针对具体情况组合评审队伍。

现象3：评审专家的状态

在评审过程中应当要有实事求是的态度，不知道的事情应当问清楚，不要不懂装懂，盲目地下结论。软件开发队伍中总有一些被业内称为"大忽悠"的人士，这种人对专业技术或行业知识一知半解、不懂装懂，却能爬得很快。他们为了掩盖自己的不足，有可能吹毛求疵地找一些小毛病，来显示自己还能发现问题。

另外，如果讨论比较激烈，因某个评审专家破坏了会议进程，可以温和地建议休会，对他进行提醒后再继续；如果某个评审专家总是迟到或早退，需要延期会议或终止会议，并报告原因。

现象4：管理者要求参加他们不应参加的评审

作者的直接管理者只有在作者邀请时，才能参加评审。级别较高的管理人员不应参加下属的评审。如果管理者没有被邀请而出现在评审会上，而作者对评审感到局促，应中止评审，并向评审拥有者解释其原因。

4.8.5  效率问题

现象1：发现了太多的缺陷

如果每次评审都发现很多缺陷，那么先不要高兴说效率高。可能需要为作者提供质量工具，以便他们自己能够有效地剔出或者防止缺陷；在每次正式评审前，进行一次快速审查确定提交文档的质量，主持人通过这次检查可以确定交付物是否符合评审的入口条件。

还可以分析缺陷模板，发现过程改进，以减少缺陷注入率。

现象2：在评审会议上重新讨论很久以前的决定，或质疑工作产品的背景

在开发的早期阶段就开始对相应的工作产品进行评审，而不要等待最终的产品完成才开始，以便一些基础错误能及早发现，问题能解决。

现象3：评审人员选择了不恰当的准备方法和分析技术

开发适合被评审的工作产品的分析技术，收集以往的数据，以便了解哪一种方法最为有效。针对不同的产品、评审目标和产品规模开发评审过程指南，以提供适当的分析技术。

现象4：注意力不集中，会议跑题

开会时东拉西扯，动不动就不着边际，离题万里。

对文档中某些术语概念的认知有差异，争执不下，纠缠不清。对于同一个词汇，不同人的理解不一样，争来争去最后才发现说的不是同一件事。

4.8.6  效果问题

现象1：评审总是发现同样的问题

可能开发者始终存在某种习惯，此时需要对他们进行适当的培训。

现象2：评审的有效性无法很好的度量

缺少良好的度量方法和手段，对效果不能很好地评价。

现象3：什么问题都完全靠会议讨论来解决。

这种想法是不切实际的，会前不做任何准备必将影响评审效果。

会上蜻蜓点水，走马观花，没有深入考察要评审的文档，以发现潜在的问题。

现象4：评审内容遗漏了关键部分

没有通过检查表来确保评审内容的完整性；对发现的问题缺乏有效的跟踪及纠正措施，没有规定跟踪责任人。

4.9  小结

同行评审是由软件工作产品生产者的同行遵循已定义的规程对产品进行的技术评审。通过同行评审，开发人员能够及时得到专家的帮助和指导，加深对软件产品的理解，有利于及早和高效地从软件工作产品中识别并消除缺陷，让软件变得更易维护，同时减少最终泄漏到产品发布时的缺陷。其主要工作第一是发现工作产品中的具体错误，第二是通过对这些错误的分类和统计，发现共同的缺陷类型和修改这类缺陷的方法，避免今后类似的缺陷发生。

同行评审的对象包括所有软件开发的中间和最终工作产品，文档审查要对文档的完整性、一致性和正确性进行同行评审。按照CMMI模型的提法，同行评审分为正式评审（Inspection）、技术审查（Technical Reviews）和走查（Walkthrough）三类，"正式评审"是正式的，后两者是常用的非正式同行评审方法。

正式评审、技术审查和走查三种形式的同行评审的重要程度不同，目的、时机、规模、准备时间、主持人、参与评审人员、成果物不尽相同，应当严格遵循其流程、步骤和注意事项进行同行评审，以保证同行评审的有效性。

同行评审的"123准则"：同行评审准备时间等于（或大于）开会时间，同行评审期间发现的缺陷数量应该是同行评审准备期间发现的缺陷数量2倍以上，同行评审发现缺陷的效率是测试发现缺陷的3倍。

要努力吸取经验教训，避免同行评审中的常见问题，如文化问题、准备问题、焦点问题、人员问题、效率问题及效果问题等。