第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开发各阶段缺陷放大图

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

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

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