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会议上