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

Jupiter Code Review Reference

备注：IE6内核的浏览器图片总是出不来，建 议使用Mozilla Firefox，Opera，谷歌浏览器

<!-- [if !supportLists]-->一、 <!-- [endif]-->Jupiter 是什么？

这里的 Jupiter 是一个开源的代码审查工具，是集成在 Eclipse 下执行代码审查工作一个很棒的工具。

可以把 Jupiter 的工作划分为 3 个阶段，（我个人认为 5 个人阶段），分别是：

Individual Phase 个人阶段，表示个人审查阶段。

Team Phase 团队阶段，表示团队审查阶段。

Rework Phase 修复阶段，表示修改 Bug 阶段。

而我觉得应 该加入：

任务定义阶 段和 BUG 确认阶段。

任务定义阶 段：是指在指派审查任务前的任务定义和分配过程。

BUG 确认阶段：是指 bug 修改结束后的重新审查和关闭 bug 阶段。

<!-- [if !supportLists]-->二、 <!-- [endif]-->如何安装 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 的工具栏出现如下图标表示安装成功。

<!-- [if !supportLists]-->三、 <!-- [endif]-->如何创建 Review ID ？

<!-- [if !supportLists]-->1、 <!-- [endif]-->我们先了解 什么是 Review ID

Review ID 代表一个审查任务，包涵了很多元素，比如审查任务 名称，描述，审查那些代码文件，审查人，审查类型，级别设置等等，而这些信息正是组成一个审查任务的基本元素。

<!-- [if !supportLists]-->2、 <!-- [endif]-->创建 ReviewID 流程

<!-- [if !supportLists]-->A、 <!-- [endif]-->在 Eclipse 右击选择要审查代码的项目

<!-- [if !supportLists]-->B、 <!-- [endif]-->选择“属 性”，如下图：

<!-- [if !supportLists]-->C、 <!-- [endif]-->进入属性页 面选择“ Review ”选项，如下图：

<!-- [if !supportLists]-->D、 <!-- [endif]-->点击右边的 “ New… ”按钮出现填写框，可以填写 ReviewID 的名称，描述。如下图：

<!-- [if !supportLists]-->E、 <!-- [endif]-->点击“ Next> ”按钮进入下一步，选择对那些代码文件进行审查， 如下图：

<!-- [if !supportLists]-->F、 <!-- [endif]-->点击“ Next> ”按钮进入下一步，选择或是新输入审查人员，如下 图：

<!-- [if !supportLists]-->G、 <!-- [endif]-->点击“ Next> ”按钮进入下一步，指定 Session 的作者，这部可以不选择，但是一般选择所审查程序 的编程人员。

<!-- [if !supportLists]-->H、 <!-- [endif]-->点击“ Next> ”按钮进入下一步，选择“ Type ， Severity ， Resolution ， Status ”的选项，同时可以修改这里选择项，这一点很有 用，在大部分的代码审查工具中这个不能做到很灵活，所以有不少弊端。但是 Jupiter 搞定了这个问题。

<!-- [if !supportLists]-->I、 <!-- [endif]-->点击“ Next> ”按钮进入下一步，确定“ Type ， Severity ， Resolution ， Status ”的默认选项。如下图：

<!-- [if !supportLists]-->J、 <!-- [endif]-->点击“ Next> ”按钮进入下一步，输入最后得审查数据放在那个目 录下，建议用日期加任务标记作为目录，

比如 :2010630TEST ，如下图：

<!-- [if !supportLists]-->K、 <!-- [endif]-->点击“ Next> ”按钮进入下一步，最后设定每个阶段的过滤器，每 个项目可以根据项目的需要设定，这里默认不变。

<!-- [if !supportLists]-->L、 <!-- [endif]-->点击“ Finish ”按钮完成 ReviewID 的设定，在工程的属性对话框里多了一条数据，这些 数据就在文件“ .jupiter ”下，这个文件在工程的文件目录下，如下图：

<!-- [if !supportLists]-->3、 <!-- [endif]-->发布 ReviewID

发布 ReviewID 的过程其实就是配合 SVN 或是 CVS 或是其他版本控制系统发布“ .jupiter ”，通过传播“ .jupiter ”，让其他人把该文件拿到同一工程下的同一目录， 即可实现下一步骤的功能。

<!-- [if !supportLists]-->4、 <!-- [endif]-->获取 ReviewID

获得的方式 主要通过同步版本控制器的“ .jupiter ”文件即可，一般是定制一个审查任务之后，发起者发出邮件，邮件里面说明此次任务的具体细节，在“ .jupiter ”里面就 是这些细节的体现。

<!-- [if !supportLists]-->四、 <!-- [endif]-->在 Individual Phase 我们应该做些什么？

<!-- [if !supportLists]-->1、 <!-- [endif]-->Individual Phase 的目标

个人阶段的 目标就是针对在 ReviewID 定义阶段指定的审查人员开始工作的出发地，他们要 从这里开始，把属于他的任务执行完成，并提交到版本控制器，有很多需要注意的细节我们在后面表述。

<!-- [if !supportLists]-->2、 <!-- [endif]-->Individual Phase 的过程

<!-- [if !supportLists]-->1) <!-- [endif]-->确认已经从 版本控制器更新了“ .jupiter ”文件。

<!-- [if !supportLists]-->2) <!-- [endif]-->点击 Jupiter 的 Eclipse 图标的下拉箭头，出现 4 个选项，选择 1 Individual Phase ，即可进入选择 ReviewID 界面。如下图：

<!-- [if !supportLists]-->3) <!-- [endif]-->选择 ReviewID 界面，如下图：

<!-- [if !supportLists]-->4) <!-- [endif]-->点击“ Finish ”按钮，进入 Individual Phase 视图，图下图：

<!-- [if !supportLists]-->5) <!-- [endif]-->点击“ ReviewTable ”视图的 按钮，出现可以选的待审查的代码文件列表，如下 图：

<!-- [if !supportLists]-->6) <!-- [endif]-->选择其中你 想审查的文件，那么在 Eclipse 的编辑区即打开该文件。这时候，你可以开始你的 Review 工作了。

<!-- [if !supportLists]-->7) <!-- [endif]-->找到一个 Bug ，那怎么办？选择代码行，右击，选择“ Add Review Issue…”, 如下图：可记录改 BUG 的所有信息，并分类型，严重等级等。填写之后点击 右边的 保存按钮，形成一条审查记录。

<!-- [if !supportLists]-->8) <!-- [endif]-->这时候在代 码文件行号的位置出现一个小图标，说明这行代码有问题，同时在“ ReviewTable “视图增加了一条记录。如下图：

<!-- [if !supportLists]-->3、 <!-- [endif]-->结束 Individual Phase

个人审查阶 段就是这么一个一个问题的叠加的，直到你完成所有代码文件的审查工作，这之后刷新工程项目的目录，在目录的下面会增加一个子目录“ 2010630TEST ” [ 不一定就这个名称，这是根据你在定义 ReviewID 时数据而定 ] ，里面有一个文件“测试代码审查任务 -XXX.review ”。其中“ - ”的前一部分是 ReviewID 名称，后一部分的 XXX 是执行 Individual 的 ReviewerID ，也就是审查者。文件的后缀是 .review 。提交 .review 文件到版本控制系统，并回复执行的任务邮件告知审 查发起者你的任务已经完成，在回复时记得把 .review 文件名称写在邮件里面。

<!-- [if !supportLists]-->五、 <!-- [endif]-->在 Team Phase 我们讨论些什么？

<!-- [if !supportLists]-->1、 <!-- [endif]-->Team Phase 的目标

Team Phase 的目标就是把很多审查人的审查文件集合起来然后， 开个评审会议，把问题讨论清楚，确认是否需要调整或是制定给谁解决等。

<!-- [if !supportLists]-->2、 <!-- [endif]-->Team Phase 的过程

<!-- [if !supportLists]-->1) <!-- [endif]-->进入 Team Phase ，操作如下图：

<!-- [if !supportLists]-->2) <!-- [endif]-->进入下图， 选择讨论哪个审查者审查出来的问题。

<!-- [if !supportLists]-->3) <!-- [endif]-->点击“ Finish ”按钮，进入 BUG 的浏览界面面，如下图：

<!-- [if !supportLists]-->4) <!-- [endif]-->那么如何讨 论一个审查出来的 BUG 呢，双击“ Review Table ”里面的一个 Bug ，在 Eclipse 的编辑区即可导航到该代码行，而在“ Review Edit ”则打开该 Bug 的具体描述，可以指定给那个开发人员修改 [ 默认是在设定改 ReviewID 时指定的 Session Author ] ，可以设定“ Resolution” 的选项，并添加备注。如下图：

<!-- [if !supportLists]-->5) <!-- [endif]-->最后点击保 存，结束一个 Bug 的讨论。

<!-- [if !supportLists]-->3、 <!-- [endif]-->结束 Team Phase

依次循环， 逐个解决审查出来的 Bug ，并提交 .review 文件到版本控制器，并邮件通知代码修改人员。每个 Bug 都应该得到重视，讨论时一种很好的传播方式，所以 在结束 Team Phase 前，一定要把问题总结出来，尽可能的避免下次再次 出现。

<!-- [if !supportLists]-->六、 <!-- [endif]-->在 Rework Phase 修改 Bug

<!-- [if !supportLists]-->1、 <!-- [endif]-->Rework Phase 的目标

Rework Phase 的目标就是每个开发人员去看看被检查出来的 bug ，并彻底的修复它，不要留下任何给检查者在 Reopen 的机会。

<!-- [if !supportLists]-->2、 <!-- [endif]-->Rework Phase 的过程

<!-- [if !supportLists]-->1) <!-- [endif]-->进入 Rework Phase ，操作如下图：

<!-- [if !supportLists]-->2) <!-- [endif]-->同样需要选 择对应的项目和对应的 Review 信息，如下图：

<!-- [if !supportLists]-->3) <!-- [endif]-->一般这时候 不一定可以在“ Review Table ”看得到 BUG 记录，需要选择“ Review Table ”的过滤按钮 才能看到 Bug 记录。

<!-- [if !supportLists]-->4) <!-- [endif]-->Ok ，逐个双击，导航到代码，逐个修改，修改之后在“ Review Editer ”调整该 Bug 的信息。如下图：

其中状态可 以改成 Resolved ，表示已经解决问题；或是 Closed 表示直接关闭，或是 Reopen ，重新开启（最好不要被重新开启）。

<!-- [if !supportLists]-->3、 <!-- [endif]-->结束 Rework Phase

逐个解决 Bug ，逐个修改它的状态，最后提交 .review 文件到版本控制系统，并邮件通知代码审查人员可以 重新审查已经修改的 Bug 了。

<!-- [if !supportLists]-->七、 <!-- [endif]-->确认修改

<!-- [if !supportLists]-->1、 <!-- [endif]-->可能不需要 这一步骤

有些团队可 能不需要这一步骤，但是这只是建议，应为他们的人手不够，而且每个开发人员都值得信任，每个修改者在修改完 bug 之后直接 close 了 bug 。直接进入报表生成阶段。而我觉得这一步骤在很多 场合很有必要，比如需要有人来证明你的 bug 确实解决了。

<!-- [if !supportLists]-->2、 <!-- [endif]-->如何重新审 查

进入重新审 查的过程和进入 Rework Phase 的过程一样，只需要查看 Bug 修改情况和调整 Bug 的状态即可。

<!-- [if !supportLists]-->3、 <!-- [endif]-->结束审查

结束审查之 后需要邮件通知所有相关人员您的重新审查情况。

<!-- [if !supportLists]-->八、 <!-- [endif]-->分析 .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 >

<!-- [if !supportLists]-->九、 <!-- [endif]-->把 .review 文件变成报表

因为到最后 可能有很多的 .review 文件，我们需要把他们全比合并起来，于是我们可以 写一个 Eclipse 插件或是写一个独立的应用来完成这个工作，把多个 .review 文件合并成一个 .review 文件，合并的目的在于我们要利用 iReport 来帮我们完成报表的建立。如何制作一个报表参考 iReport 的使用。

本文完成 时，“ JE ”合并工具还没有最后完成，但是界面已经出来，可 以先拿来参考，最后的报表也还没有实现，这部分内容需要通过 iReport 实现，放在后续的文章说明。