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
实现，放在后续的文章说明。