同行评审的5个要点

笔者所知道的所有软件公司，无论规模大小，都正式或者非正式的进行了同行评审。但是对于同行评审，并非每个公司都取得了期望的成果，这种现象的存在很大一部分的原因在于很多公司只明白了同行评审的操作方式而对其背后的思想不甚了了，在日常的操作中也只是照猫画虎，忽视了同行评审的要点。笔者根据自己所经历的及所知道的一些组织的同行评审情况进行了一些分析，得出了同行评审的以下要点：

1、思想
中国人常说的同行评审更多包含了“评价”的意味，目的是验证正确性，而实际上，同行评审的本意是Review，即复查的意思，目的在于找出问题。这一点必须成为所有组织、参加评审会人员应建立的共识。
可是，我们经常听到“评审通过了”这样的话从被评审工作产品承制者口中说出来，听上去似乎在说“我的工作真牛”。就像我们不想花大量的测试成本来验证自己的程序无错一样，采用成本昂贵的评审技术也不是为了验证被评审工作产品是无错的，而是帮助我们尽早的发现问题、找到错误，避免问题延误到后期解决而付出惨痛的代价。

2、方法
统一了思想以后，接下来的重点就是“方法得当”！为什么呢？因为相对而言，中国文化中还是比较缺乏“评审文化”的。中国人通常不愿意接受“当面指出问题”这种沟通方式，更不要说“众目睽睽”之下被人指出问题。
而且，在软件开发团队中评审的价值并没有得到很多的认同，大家就更难从心里接受和赞同同行评审活动。要想慢慢的创建企业的评审文化，就必须建立对这种评审活动的认同，而要建立对评审活动的认同，就必须看到评审的效果；而要看到评审的效果，最快的是通过正式化程度较低的评审手段。

3、语言
如果说前面讲的是中国人通常不是好的、积极的“被评审者”，那么这里想要说的是，中国人还经常不是好的、有效地“评审者”。
“你这个地方有问题......”
“你这个地方错了......”
“你这里怎么能这么写，应该写成......”
设想一下，当这样的语言朝你飞来的时候，你会做出何种反应呢？这种不良的语言习惯是破坏评审会气氛的一大杀手，因为你一不小心就变成了高高在上的“评价者”。
实际上，在评审会中大家应以“建议者、协作者”的身份、角色出现在会议中，这首先需要大家改变评审时的语言习惯，最重要的是将“你......”改成“我......”，如：

“你这个地方有问题......” --> “我没有看懂，你能解释一下吗？”
“你这个地方错了......” --> “按我的理解，这个地方和实际情况有些不一致，建议确认一下”
“你这里怎么能这么写，应该写成......” --> “如果我写的话，我会写为......”

4、人员
要开好评审会，选择合适的参与人员是很重要的：要点在于合适，而非越多越好。具体来说，包括以下几个方面：

同级：同行评审的原文是“Peer Review”，Peer的意识就是同级，千万不要一开评审会就请高级领导，很多人连“当着别人的面被指出问题”都受不了，何况是当着领导的面啊。

该来的人要请：对于评审内容所涉及的第一责任人，一定要请他们参加

不该来的人不要请：评审应保持尽量小的范围，要直接的相关人员参与，一方面可以保证参与者对评审内容很熟悉，另一方面可以保证参与者关心同行评审。

5、内容
有一次，笔者参加一个需求分析的同行评审会，却发现同行评审的内容有300多页，评审时间为2个小时。试问，如此多的内容可以在2个小时内得到充分评审吗？
每次评审应选择合适范围的内容，不应求大求全，对于规模较大的评审内容，应对评审内容进行拆分，分为几次评审，这样才可以保证评审的效果。
那应如何对大规模的评审内容进行拆分呢？其实在软件设计中有“高内聚低耦合”的设计原则，在评审内容的拆分上，可以充分借鉴“高内聚低耦合”的原则，使每次评审的内容内部关联性最高。