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