Jupiter Code Review Reference--Jupiter Code review tool use reference (modified version)

Jupiter Code Review Reference

Note: IE6 kernel browser images are always out of the picture, it is recommended to use Mozilla Firefox,opera, Google Chrome

What is Jupiter?

The Jupiter here is an open source code review tool that is a great tool for integrating code review work under Eclipse.

Jupiter's work can be divided into 3 stages (I personally think 5 stages), respectively:

Individual Phase individual stage, which represents the individual review phase.

Team Phase group stage, which represents the team review phase.

Rework Phase repair phase, which indicates that the BUG phase is modified.

And I think we should join in:

The task definition phase and the BUG confirmation phase.

Task definition phase: Refers to the task definition and allocation process before assigning a review task.

Bug Confirmation phase: Refers to the re-examine and close the bug phase after the bug has been modified.

Second, how to install Jupiter

Condition: Jupiter requires Java 5 or later JDK and Eclipse3.3 (Europa) or later Eclipse. Since Jupiter is based on team work, it is recommended that code hygiene review work be performed under a version control system. (i.e. CVS or SVN, etc.).

Installation: [This is only available for Eclipse3.5 Galileo offline installation, the address installed via the online installation is: http://jupiter-eclipse-plugin.googlecode.com/svn/trunk/site/please decide for yourself ]

The first step:

Download the latest JAR file to Http://code.google.com/p/jupiter-eclipse-plugin/downloads/list.

Step Two:

Copy the downloaded JAR file to Eclipse's plugins directory.

Step Three:

Restart Eclipse (or open Eclipse) if the toolbar in eclipse appears as a mark indicating that the installation was successful.

Third, how to create Review ID?

1, we first understand what is Review ID

The Review ID represents a review task that includes many elements, such as reviewing task names, descriptions, reviewing those code files, reviewing people, examining types, level settings, and so on, which are the basic elements of a review task.

2. Create Reviewid Process

A. Right-click on Eclipse to select the project to review the code

B. Select "Properties", such as:

C, go to the Properties page select the "Review" option, such as:

D. Click on the "New ..." button on the right. "button appears fill box, you can fill in the name of Reviewid, description. Such as:

E, click on the "Next>" button to enter the next step, choose to review those code files, such as:

F, click on the "Next>" button to enter the next step, select or enter a new reviewer, as shown below:

G, click on the "Next>" button to enter the next step, specify the Session of the author, this can not be selected, but generally choose the program to review the programmer.

H, click the "next>" button to enter the next step, select "Type, Severity, Resolution, Status" option, but also can modify the selection here, this is very useful, in most of the code review tool This can not be very flexible, so there are many disadvantages End. But Jupiter fixed the problem.

I, click the "next>" button to enter the next step, determine the "Type, Severity, Resolution, Status" of the default options. Such as:

J, click on the "Next>" button to enter the next step, enter the final review data in that directory, it is recommended to use the date and task tags as a directory,

For example: 2010630TEST, such as:

K, click on the "Next>" button to enter the next step, and finally set each stage of the filter, each project can be set according to the needs of the project, the default is not changed here.

L, click "Finish" button to complete the Reviewid settings, in the Project Properties dialog box more data, the data in the file ". Jupiter", the file in the project file directory, such as:

3, Release Reviewid

The process of releasing the Reviewid is to release ". Jupiter" with SVN or CVS or other version control systems, allowing others to take the file to the same directory under the same project, enabling the next step to function.

4. Get Reviewid

The method obtained is mainly by synchronizing the ". Jupiter" file of the version controller, usually after a review task is customized, the initiator sends out an email stating the specific details of the mission, in the " . Jupiter " Inside is the embodiment of these details.

Iv. What should we do in individual Phase?

1. The target of individual Phase

The goal of the personal phase is to start the work of the examiners specified in the REVIEWID definition phase, starting from here, taking the tasks that belong to him and submitting them to the version controller, and there are a lot of details that need to be noted in the following statement.

2, the process of individual Phase

1) Confirm that the ". Jupiter" file has been updated from the version controller.

2) Click the drop-down arrow of the Eclipse icon in Jupiter, 4 options appear, select 1 individual Phase to enter the Reviewid interface. Such as:

3) Select the Reviewid interface, such as:

4) Click "Finish" button to enter individual Phase view, figure:

5) Click on the "reviewtable" View button, there is a list of optional code files to be reviewed, as shown below:

6) Select the file you want to review, then open the file in the edit area of Eclipse. At this time, you can start your Review work.

7) Find a Bug, what should I do? Select the line of code, right-click, select "Add Review Issue ...", such as: can record all the information to change the BUG, and classification type, severity rating. After filling in, click the Save button on the right to form a review record.

8) A small icon appears at the line number of the code file, which indicates a problem with this line of code, and adds a record in the "reviewtable" view. Such as:

3. End individual Phase

The individual review phase is such a matter of overlapping, until you complete all the code file review work, after this refresh project directory, under the directory will be added a subdirectory "2010630TEST" [not necessarily the name, which is based on the data you define REVIEWID] , which has a file "Test code Review Task-xxx.review". The first part of the "-" is the Reviewid name, and the latter part of XXX is the ReviewerID that performs individual, that is, the reviewer. The suffix of the file is. Review. Submit the. Review file to the version control system, and reply to the task message to inform the review initiator that your task is complete and remember to write the. Review file name in the message when replying.

V. What are we discussing in Team Phase?

1. Goal of Team Phase

Team Phase's goal is to assemble a lot of censors ' review papers and then open a review session to discuss the issues clearly, to see if they need to be adjusted or to be worked out.

2, the Team Phase process

1) Enter Team Phase and operate as follows:

2) Enter, and choose to discuss which reviewer examines the issue.

3) Click "Finish" button to enter the browser interface of the BUG, such as:

4) So how to discuss a review of the bug, double-click "Review Table" inside a bug, in the edit area of Eclipse can navigate to the line of code, and in "Review edit" open the specific description of the BUG, you can assign to that development Staff modification [default is the Session Author specified when setting the change Reviewid], you can set the "Resolution" option, and add notes. Such as:

5) Finally click Save to end a discussion of the Bug.

3. End Team Phase

Loop through, fix the bugs that are reviewed, and submit the. Review file to the version controller, and email the code to notify the person who modified it. Each Bug should be taken seriously, the discussion is a good way to spread, so before the end of Team Phase, be sure to summarize the problem, as far as possible to avoid the next time.

Vi. modifying bugs in rework Phase

1. The target of rework Phase

The goal of rework Phase is for each developer to look at the bugs that have been checked out and fix it thoroughly without leaving any chance for the inspectors to Reopen.

2, the process of rework Phase

1) Enter rework Phase, operation such as:

2) also need to select the corresponding project and corresponding Review information, such as:

3) Generally this time may not be able to see the "Review table" bug record, you need to select the "Review table" filter button to see the bug record.

4) Ok, double-click, navigate to the code, modify it one after the other, modify the information in "Review editer" to adjust the Bug. Such as:

Where the state can be changed to resolved, indicating that the problem has been resolved, or Closed means direct shutdown, or Reopen, re-open (preferably not re-opened).

3. End Rework Phase

Resolve the bug one by one, modify its state one by one, and finally commit the. Review file to the version control system, and email the code reviewer to re-examine the bug that has been modified.

Vii. Confirmation of Changes

1. This step may not be required

Some teams may not need this step, but it is only recommended that they are not staffed enough, and that each developer is trustworthy and that each modifier immediately close the bug after modifying the bug. Go directly to the report generation stage. And I think this step is necessary on many occasions, such as needing someone to prove that your bug is really solved.

2. How to re-examine

As you go through the process of re-examination and the process of entering rework Phase, just review the bug changes and adjust the status of the bug.

3. End of review

After the review, you will be required to notify all relevant personnel of your re-examination.

Viii. analysis. Review file

The. Review file is structured in XML format, with each label indicating a practical meaning, let's look at how it describes the problem:

<?xml version= "1.0" encoding= "UTF-8"?>

< Review id = "Test code review Task" > <!-represents the name of the Review ID that we defined

< reviewissue ID = "Gb1uv3so" ><!-represents an automatically generated Bug corresponding to the id->

< Reviewissuemeta >

< CreationDate > 2010-06-30:: 15:38:57:144 CST </creationdate ><!-What time was created bug->

< Lastmodificationdate > 2010-07-01:: 14:18:02:631 CST </lastmodificationdate ><!-Last modified time,

</Reviewissuemeta >

< ReviewerID > LV wide ditch </reviewerid ><!-the person who found the bug

< AssignedTo > Millet </assignedto ><!-the person who modified the bug

< file line = "Src/com/jem/report/exam/xml/xmldatasourceexample.java" > </file ><!-bug specific location,

< types > item.type.label.programLogic </type ><!-bug

< Severity > item.severity.label.normal </Severity ><!-bug severity rating

< Summary > Extra code </Summary > <!-bug Description Title

< Description > This statement is superfluous in this statement and has no practical use. Description of </Description ><!-bug

< Annotation > So </Annotation ><!-bug annotations,

< Revision > Yes </Revision ><!-bug adjustment notes,

< Resolution > Item.resolution.label.validFixlater </Resolution ><!-bug resolution options,

< status > item.status.label.closed </status ><!-bug last state

</reviewissue >

</Review >

Ix. turning the. Review file into a report

Because there may be a lot of. Review files in the end, we need to merge them all together, so we can write an Eclipse plugin or write a standalone application to do the work, merging multiple. Review files into a single. Review file, and the purpose of merging is to use IReport to help us complete the establishment of the report. How to make a report reference IReport use.

The completion of this article, "JE" merge tool has not been finalized, but the interface has come out, you can refer to, the final report has not been implemented, this part of the content needs to be implemented through IReport, put in the following article description.

Jupiter Code Review Reference--Jupiter Code review tool use reference (modified version)