Jupiter Code Review Reference -- Jupiter代码审查工具使用参考 (修改版)

原创 2010年07月06日 10:43:00
  • 14570

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

05-02 19:01