ode reviews are possibility the single most efficient way to reduce defects and improve code quality. Simply put, code reviews involve manually inspecting source code for defects, often using a checklist of common errors to help focus the search. In addition, they are an effective way of improving your team's development skills.

To be effective, all code review techniques need an underlying process that all team members must understand well and adopt. In general, if you want to introduce a new development process or best practice into an organization, it should be as simple as possible. As Einstein once said, "Things should be made as simple as possible—but no simpler."

Heeding Einstein's advice, Jupiter, a collaborative Eclipse code review tool, uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an XML file format and maintains them in the project configuration management system alongside the source code.

This article walks you through a Jupiter install and the stages of a Jupiter code review process.

Installing Jupiter

The easiest way to install Jupiter is to use the Remote Update site. Launch Eclipse and perform the following instructions:

• Open the Help->Software Updates->Find and Install menu.
• Click Next, and choose New Remote Site.
• Enter the remote site URL (http://csdl.ics.hawaii.edu/Tools/Jupiter/Update2), and the site name (e.g., "Jupiter") (see Figure 1).
• Make sure you have the Jupiter site checked in the "Sites to include in search" window, and click Finish. Then just go through the installation screens to install the plug-in.

  

  Figure 1. Installing from the Remote Site

The Jupiter Code Review Process

The code review process implemented in Jupiter is relatively simple, and it should suffice for most projects. In Jupiter, you conduct a code review in the following four stages:

1. Configuration: The review initiator sets up the review, defining a unique "Review ID" and specifying the files to be reviewed, who will review the code, and what issues can be raised. Depending on your organization, the review initiator could be the author, the team leader, or someone in QA.
2. Individual review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them.
3. Team review: The review team (including the author) meet to discuss issues and decide on actions to take.
4. Rework: The developer goes through the raised issues and fixes them.

For completeness, you should also add a preliminary phase, the personal code review, where the developer reviews his or her own code.

Let's look at each of these stages in more detail.

Personal Code Review

Personal code reviews are a highly effective practice that plays an important part in the Software Engineering Institute's Personal Software Process. A personal code review simply involves reading through the code and using the review checklist to look for errors.

Using a review checklist is an important part of the review process. Reviews are much more efficient when you have precise goals in mind. With a review checklist, you actively hunt specific bugs; whereas without one, you just wander through the code hoping to come across one.

A review checklist contains defects or categories of defects that are known to have caused problems in the past. If you are already using tools like Checkstyle and PMD, you don't need to add any coding standards or duplicate any best practices that those other tools already have verified. Keep it short and simple to begin with, and then add new items as you come across them. And don't forget to get everyone involved.

One notable difference between the approach described here and the personal review process recommended in the Personal Software Process is that, in the latter, the individual review comes before compiling the code. One of the main arguments for this is that reviews conducted before compilation tend to be more thorough. Another reason probably is that if you let the tools find all the compilation errors, as well as the coding standards violations and other best practices errors, you will have a harder time tracking the number of issues raised.

However, knowing how hard it is to put any sort of rigorous software development process into place, I believe in getting the most leverage out of your available tools and reserving human involvement for work that only humans can do. Indeed, if you want to introduce a new process into an organization, you should put as few obstacles as possible in the way and make the process as painless as possible.

The following is a simple strategy for performing a personal code:

1. Obtain the code review checklist and display the class to be reviewed.
2. Run through the defect categories in the checklist. For each category, go through the code and make sure it isn't an issue. If it is, either fix it (if it will take less than 30 seconds) or note it for later. Check off each item you finish.
3. Once finished, fix any outstanding issues.

Once this is done, the peer review process can begin.