Peer Review 浅析

Peer Review

(070620 [e-mail] 李宁)

PR的概念和目的

    Peer Review又名同级评审或一对一评审，同级评审的目的是为了要检查工作的内容，尽早的找到和修正问题。 PR的流程是可以根据条件和时间灵活的制定。

    假设小组不只是您一个人组成，那么您应该与组员一起评审工作当中各个方面如功能和事务。花一些时间对作些评审对工作的质量会有很大的改善，同级评审通常是由作者在小组面前检查他自己的工作。-- Rex。

    目的：

l        同行评审不仅是为了找出缺陷，也是为了正确性验证。

l        同行评审不同于正式的技术评审，评审人一般是指担负同一层面任务的人。 比如都在执行编程或单元测试或详细设计或总体设计或需求分析等工作。

l        在软件开发过程中，凡是可以分为并行的若干单个个体并且这些个体的缺陷影响不会扩展给其它个体的结果（或者说有但较易控制），均可以考虑进行同行评审。对于需求分析，除非能按几大类分得很隔离，否则由于我们要验证需求的一致性（即不矛盾）、不重复性（这些需要进行全盘考虑）时，就不能进行所谓的同行评审来验证这些特性。对于概要设计也是如此。
对于详细设计、编码、单元测试这些开发活动就完全可以在项目经理或小组负责人的安排下进行同行评审就很有意义。

l        P2P开发流程是一种交流形的开发方式， 使开发人员之间增加了交流，同时也是彼此之间有了共同学习与进步，从而达到了代码规范及风格趋向一致。

PR的应用条件

l        同行评审一般是在比较成熟的而且参与者已对评审的尺度达成了共识（比如需求分析说明书中需求要细到什么程度，对用语有什么约束等等）的时候才考虑应用，也就是说此时参与者对任务及成果本身有着清晰而共则的理解和认识。（对于未达成评审共识以及涉及影响系统结构的争论不应当放到PR上，而应当例会使内部达成共识）
正式的技术评审不管参与者是否对任务有清晰的认识，做为阶段性成果的验收机制，也肯定是要进行的。

l        正式的技术评审可以邀请项目外的权威或高手参加，对于较重要的任务和成果，同行评审可作为初步的评审。然后再考虑进行正式的技术评审。正式的技术评审可作为产品或任务完成的认可机制。而同行评审只有在项目团队有清晰而成熟的认识时才可作为一个认可机制，如对详细设计书和源程序的同行评审。

l        有效的P2P开发的前提是开发模块和内容要足够细化和明确化，换言之，是需要开发前的程序设计及架构分析透明化或局部透明化。因此在一些重构项目中或在一些新的项目中去应用P2P的开发模式比较适合。（如果长时间未进行PR过程，积累了大量的代码和文档，此时要注入PR评审流程的话前期工作的困难会非常大）。

l        评审的代码量一次不能过大，否则会给评审者带来很大的理解和时间上的负担。

PR的实施

基本的同级评审过程如下所述：

1.    提前几天散发草案文档，然后安排一间会议室。

2.    邀请组内几个能够参与的人，尽力将每个人都引入到讨论中。

3.    逐一创造一种畅所欲言的评审气氛。

4.    浏览文档和代码，应在重要细节上花费大量时间，但要防止在次要问题上浪费时间。

5.    在任何一部分中都要避免花费2小时以上时间。很难在高技术资料上长时间保持效率。

6.    评审完成后，重新修订该文档和代码，并将它通知给与会者，确保正确理解了评审的结论和思想。

7.    参与人数一般根据被评审对象的重要性来定，越重要参加的人就越多。

8.    同行评审的人数不是越多越好的，一般不能超过8个，评审的时间（包括会前准备）的时间也不能太长，一般不超过2个小时；开发过程所有的产品都可以被评审，评审的目的还是为了寻找Defect。一般评审前，应该有统一的，供参考的标准，对照标准进行评审，包括技术上是否正确，写法是否符合标准，和其他产品是否一致等等，都是同行评审关心的。最后，同意楼上的，能够在实践中使用，就会明白最适合自己项目的是什么，方法也是活的，可以不断调整的。

 

公司内部的评审的尝试：

在公司内部我们也有很多小组尝试了PR的评审机制,但是大都遇到了不小的障碍，但是归结一下问题的表现共有三个：

1、 不同人员之间对与模块的理解上的差异导致在疏导基本知识的沟通时间很长；

2、 对评审人的工作有打断；

3、 代码和工作量过大导致评审无法进行。

 

实施图：