Jupiter Code Review Reference -- Jupiter代码审查工具使用参考 （修改版）
Jupiter Code Review Reference
备注：IE6内核的浏览器图片总是出不来，建 议使用Mozilla Firefox，Opera，谷歌浏览器
一、 Jupiter 是什么？
这里的 Jupiter 是一个开源的代码审查工具，是集成在 Eclipse 下执行代码审查工作一个很棒的工具。
可以把 Jupiter 的工作划分为 3 个阶段，（我个人认为 5 个人阶段），分别是：
Individual Phase 个人阶段，表示个人审查阶段。
Team Phase 团队阶段，表示团队审查阶段。
Rework Phase 修复阶段，表示修改 Bug 阶段。
而我觉得应 该加入：
任务定义阶 段和 BUG 确认阶段。
任务定义阶 段：是指在指派审查任务前的任务定义和分配过程。
BUG 确认阶段：是指 bug 修改结束后的重新审查和关闭 bug 阶段。
二、 如何安装 Jupiter
条件： Jupiter 需要 Java 5 或更高版本的 JDK 以及 Eclipse3.3 （ Europa ）或更高版本Eclipse 。由于 Jupiter 是基于团队的工作，建议在一个版本控制系统下执行 代码生审查工作。（即 CVS 或 SVN 等）。
安装： [ 这里只提供针对 Eclipse3.5 Galileo 的离线安装，通过在线安装的地址是：http://jupiter-eclipse-plugin.googlecode.com/svn/trunk/site/ 请自行决定 ]
第一步：
到 http://code.google.com/p/jupiter-eclipse-plugin/downloads/list下载最新的JAR 文件。
第二步：
把下载到的 JAR 文件拷贝到 Eclipse 的 plugins 目录下。
第三步：
重启 Eclipse （或是打开 Eclipse ）如果在 Eclipse 的工具栏出现如下图标表示安装成功。
三、 如何创建 Review ID ？
1、 我们先了解 什么是 Review ID
Review ID 代表一个审查任务，包涵了很多元素，比如审查任务 名称，描述，审查那些代码文件，审查人，审查类型，级别设置等等，而这些信息正是组成一个审查任务的基本元素。
2、 创建 ReviewID 流程
A、 在 Eclipse 右击选择要审查代码的项目
B、 选择“属 性”，如下图：
C、 进入属性页 面选择“ Review ”选项，如下图：
D、 点击右边的 “ New… ”按钮出现填写框，可以填写 ReviewID 的名称，描述。如下图：
E、 点击“ Next> ”按钮进入下一步，选择对那些代码文件进行审查， 如下图：
F、 点击“ Next> ”按钮进入下一步，选择或是新输入审查人员，如下 图：
G、 点击“ Next> ”按钮进入下一步，指定 Session 的作者，这部可以不选择，但是一般选择所审查程序 的编程人员。
H、 点击“ Next> ”按钮进入下一步，选择“ Type ， Severity ， Resolution， Status ”的选项，同时可以修改这里选择项，这一点很有 用，在大部分的代码审查工具中这个不能做到很灵活，所以有不少弊端。但是 Jupiter 搞定了这个问题。
I、 点击“ Next> ”按钮进入下一步，确定“ Type ， Severity ，Resolution ， Status ”的默认选项。如下图：
J、 点击“ Next> ”按钮进入下一步，输入最后得审查数据放在那个目 录下，建议用日期加任务标记作为目录，
比如 :2010630TEST ，如下图：
K、 点击“ Next> ”按钮进入下一步，最后设定每个阶段的过滤器，每 个项目可以根据项目的需要设定，这里默认不变。
L、 点击“ Finish ”按钮完成 ReviewID 的设定，在工程的属性对话框里多了一条数据，这些 数据就在文件“ .jupiter ”下，这个文件在工程的文件目录下，如下图：
3、 发布 ReviewID
发布 ReviewID 的过程其实就是配合 SVN 或是 CVS 或是其他版本控制系统发布“.jupiter ”，通过传播“ .jupiter ”，让其他人把该文件拿到同一工程下的同一目录， 即可实现下一步骤的功能。
4、 获取 ReviewID
获得的方式 主要通过同步版本控制器的“ .jupiter ”文件即可，一般是定制一个审查任务之后，发起者发出邮件，邮件里面说明此次任务的具体细节，在“.jupiter ”里面就 是这些细节的体现。
四、 在 Individual Phase 我们应该做些什么？
1、 Individual Phase 的目标
个人阶段的 目标就是针对在 ReviewID 定义阶段指定的审查人员开始工作的出发地，他们要 从这里开始，把属于他的任务执行完成，并提交到版本控制器，有很多需要注意的细节我们在后面表述。
2、 Individual Phase 的过程
1) 确认已经从 版本控制器更新了“ .jupiter ”文件。
2) 点击 Jupiter 的 Eclipse 图标的下拉箭头，出现 4 个选项，选择 1 Individual Phase ，即可进入选择 ReviewID 界面。如下图：
3) 选择 ReviewID 界面，如下图：
4) 点击“ Finish ”按钮，进入 Individual Phase 视图，图下图：
5) 点击“ ReviewTable ”视图的 按钮，出现可以选的待审查的代码文件列表，如下 图：
6) 选择其中你 想审查的文件，那么在 Eclipse 的编辑区即打开该文件。这时候，你可以开始你的 Review 工作了。
7) 找到一个 Bug ，那怎么办？选择代码行，右击，选择“ Add Review Issue…”, 如下图：可记录改 BUG 的所有信息，并分类型，严重等级等。填写之后点击 右边的 保存按钮，形成一条审查记录。
8) 这时候在代 码文件行号的位置出现一个小图标，说明这行代码有问题，同时在“ ReviewTable “视图增加了一条记录。如下图：
3、 结束 Individual Phase
个人审查阶 段就是这么一个一个问题的叠加的，直到你完成所有代码文件的审查工作，这之后刷新工程项目的目录，在目录的下面会增加一个子目录“2010630TEST ” [ 不一定就这个名称，这是根据你在定义 ReviewID 时数据而定 ]，里面有一个文件“测试代码审查任务 -XXX.review ”。其中“ - ”的前一部分是ReviewID 名称，后一部分的 XXX 是执行 Individual 的 ReviewerID ，也就是审查者。文件的后缀是 .review 。提交 .review 文件到版本控制系统，并回复执行的任务邮件告知审 查发起者你的任务已经完成，在回复时记得把 .review 文件名称写在邮件里面。
五、 在 Team Phase 我们讨论些什么？
1、 Team Phase 的目标
Team Phase 的目标就是把很多审查人的审查文件集合起来然后， 开个评审会议，把问题讨论清楚，确认是否需要调整或是制定给谁解决等。
2、 Team Phase 的过程
1) 进入 Team Phase ，操作如下图：
2) 进入下图， 选择讨论哪个审查者审查出来的问题。
3) 点击“ Finish ”按钮，进入 BUG 的浏览界面面，如下图：
4) 那么如何讨 论一个审查出来的 BUG 呢，双击“ Review Table ”里面的一个Bug ，在 Eclipse 的编辑区即可导航到该代码行，而在“ Review Edit ”则打开该 Bug 的具体描述，可以指定给那个开发人员修改 [ 默认是在设定改ReviewID 时指定的 Session Author ] ，可以设定“ Resolution” 的选项，并添加备注。如下图：
5) 最后点击保 存，结束一个 Bug 的讨论。
3、 结束 Team Phase
依次循环， 逐个解决审查出来的 Bug ，并提交 .review 文件到版本控制器，并邮件通知代码修改人员。每个 Bug 都应该得到重视，讨论时一种很好的传播方式，所以 在结束 Team Phase 前，一定要把问题总结出来，尽可能的避免下次再次 出现。
六、 在 Rework Phase 修改 Bug
1、 Rework Phase 的目标
Rework Phase 的目标就是每个开发人员去看看被检查出来的 bug ，并彻底的修复它，不要留下任何给检查者在 Reopen 的机会。
2、 Rework Phase 的过程
1) 进入 Rework Phase ，操作如下图：
2) 同样需要选 择对应的项目和对应的 Review 信息，如下图：
3) 一般这时候 不一定可以在“ Review Table ”看得到 BUG 记录，需要选择“ Review Table ”的过滤按钮 才能看到 Bug 记录。
4) Ok ，逐个双击，导航到代码，逐个修改，修改之后在“ Review Editer”调整该 Bug 的信息。如下图：
其中状态可 以改成 Resolved ，表示已经解决问题；或是 Closed 表示直接关闭，或是 Reopen ，重新开启（最好不要被重新开启）。
3、 结束 Rework Phase
逐个解决 Bug ，逐个修改它的状态，最后提交 .review 文件到版本控制系统，并邮件通知代码审查人员可以 重新审查已经修改的 Bug 了。
七、 确认修改
1、 可能不需要 这一步骤
有些团队可 能不需要这一步骤，但是这只是建议，应为他们的人手不够，而且每个开发人员都值得信任，每个修改者在修改完 bug 之后直接 close 了 bug 。直接进入报表生成阶段。而我觉得这一步骤在很多 场合很有必要，比如需要有人来证明你的 bug 确实解决了。
2、 如何重新审 查
进入重新审 查的过程和进入 Rework Phase 的过程一样，只需要查看 Bug 修改情况和调整 Bug 的状态即可。
3、 结束审查
结束审查之 后需要邮件通知所有相关人员您的重新审查情况。
八、 分析 .review 文件
.review 文件以 xml 格式为结构，具体的每个标签标示一个实际的意义， 我们来看看它的描述问题方式：
<?xml version="1.0" encoding="UTF-8"?>
< Review id =" 测试代码审查任务 "> <!— 表示我们定义的 Review ID 的名称 —>
< ReviewIssue id =" GB1UV3SO "><!— 表示自动生成的 Bug 对应的 ID—>
< ReviewIssueMeta >
< CreationDate > 2010-06-30 :: 15:38:57:144 CST </ CreationDate ><!— 什么时间创建的 Bug—>
< LastModificationDate > 2010-07-01 :: 14:18:02:631 CST </ LastModificationDate ><!— 最后修改时间 —>
</ ReviewIssueMeta >
< ReviewerId > 吕宽沟 </ ReviewerId ><!— 发现 bug 的人员 —>
< AssignedTo > 谷子地 </ AssignedTo ><!— 修改 bug 的人员 —>
< File line =" 60 "> src/com/jem/report/exam/xml/XmlDataSourceExample.java </ File ><!—Bug 具体位置 —>
< Type > item.type.label.programLogic </ Type ><!—Bug 的类型 —>
< Severity > item.severity.label.normal </ Severity ><!—Bug 的严重等级 —>
< Summary > 多余代码 </ Summary > <!—Bug 描述标题 —>
< Description > 这个语句在这里是多余的语句，没有实际的用处。 </ Description ><!—Bug 的描述 —>
< Annotation > 也就是这样的 </ Annotation ><!—Bug 的批注 —>
< Revision > 就是啊 </ Revision ><!—Bug 的调整备注 —>
< Resolution > item.resolution.label.validFixlater </ Resolution ><!—Bug 的解决选项 —>
< Status > item.status.label.closed </ Status ><!—Bug 最后得状态 —>
</ ReviewIssue >
</ Review >
九、 把 .review 文件变成报表
因为到最后 可能有很多的 .review 文件，我们需要把他们全比合并起来，于是我们可以 写一个 Eclipse 插件或是写一个独立的应用来完成这个工作，把多个 .review 文件合并成一个 .review 文件，合并的目的在于我们要利用 iReport 来帮我们完成报表的建立。如何制作一个报表参考 iReport 的使用。
本文完成 时，“ JE ”合并工具还没有最后完成，但是界面已经出来，可 以先拿来参考，最后的报表也还没有实现，这部分内容需要通过 iReport 实现，放在后续的文章说明。