ode review是项目过程中一项非常重要的工作,可以有效检查出代码层面的问题,而这些问题常常是QA难以发现的。但在现实工作中code review常常因为无法量化而流于形式,无法形成有效地闭环,很多时候只是在PM提醒下互相看两眼,或是组织大家开code review会议,在会议上大伙一起对着投影做集体review,效果可想而知不会太好。

解决以上的问题关键在于形成一个机制并且借助有效的工具去实施,这一点上可以借鉴QA的bug系统,对每一个有问题的点建立问题发现、问题分配和问题解决等生命周期,并且记录在案,使每个code reviewer担当起类似QA的职责。

code review机制

code review机制和流程可见下图所示:

整个流程下来关键在于所有code review的工作能把项目所有人纳入进来,而不只是Leader或项目核心成员的事情,另外要把每个issue形成闭环,让发现的问题正在得到解决

具体实施方法

实施的方法是根据所定的机制和流程而来,对于上面的流程通过一个excel也能完成,但不适合整个team并行来做,Jupiter就是一个为了让整个team来做review的工具,它是一个eclipse plugin,因此能很好和需要review的code结合起来,非常方便。下面讲一下通过Jupiter来完成以上流程的具体步骤(安装就不多说了,eclipse里面直接更新http://jupiter-eclipse-plugin.googlecode.com/svn/trunk/site/即可):

1)Coder把需review的code提交给Reviewer

某个模块的开发者完成代码后需要把涉及到的代码提交给Reviewer

进入项目的Properties面板,选择Review子面板:

新建一个Review单元,按照新建流程一路下去即可,关键在Reviewer Setting面板里指定谁来review你的代码,如下例所示:

在Author Setting面板里指定谁对这个代码负责,一般都是这个代码的coder,如下例所示:

以上的指定就是要弄明白review过程中的各个角色,其他选项就根据需要指定即可,使用默认也行。

新建一个review单元后得把产生的.review文件commit上去,因为所有的流程和动作都是基于这个文件,大家的合作就是基于这个文件的版本管理,所以只有commit这个文件才算是提交了一个review单元,Reviewer才能感知到这个review项

2)Reviewer review提交给自己的code并注明意见

Reviewer更新所有.review文件后,进入Jupiter的Individual阶段:

在Reviewer ID里选择代表自己的那一项,完了后即可开始具体的代码review,在review面板里能方便地找到需要review的文件:

在具体的代码行上可以加上review注释:

保存后在代码就会有个明显的标示表示这里需要修改:

完成所有review工作后commit .review文件

3)Leader根据工作量安排把issues分配给修改人

Leader更新所有.review文件后,进入Jupiter的Team阶段:

对每个issue选择分配给谁,默认是是分配给此代码的coder

4)coder修复具体的issues

coder更新所有.review文件后,进入Jupiter的Rework阶段:

可以看到所有分配给自己的修复任务,修复好后,更改status为Resolved

5)issues确认和关闭

Reviewer或Leader在Jupiter的Rework阶段查看每个issue的修复结果,确实修复好的更改status为closed,如果没有修复好的找到coder进行交流,需要集体确认和讨论的留到code review会议上

posted on 2011-12-13 15:59  一个人的天空@  阅读(1490)  评论(0编辑  收藏  举报