Jupiter代码审查工具使用参考
Posted oufu
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Jupiter代码审查工具使用参考相关的知识,希望对你有一定的参考价值。
备注: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 实现,放在后续的文章说明。
以上是关于Jupiter代码审查工具使用参考的主要内容,如果未能解决你的问题,请参考以下文章