ReviewClipse - Supporting Agile Code-Reviews Within the Eclipse IDE

Code reviews enhance software quality, so they should always be a part of our daily work. In the following article I will present an Eclipse integrated code review plug-in, developed at the Vienna University of Technology and presented at the EclipseCon 2009.

Introduction

ReviewClipse  helps developers to review the source code efficiently on a per changeset basis - the item under inspection is one changeset in the revision control system. Because of its simple design it's possible to initiate the review process on any existing project in a few minutes. All review data is stored within files, shared with the already configured Subversion repository of your project. So there is no need to setup any server-side application, apart from the already existing Subversion repository. The reviewer uses a special review editor to inspect the changesets, compares different versions of a file with the compare editor, and leaves his rating and optional comments for the commiter of the changeset. The review editor aligns with the basic concepts of the Eclipse environment, so the initial training will consume little time.

Installation

In order to use ReviewClipse you need at least Eclipse Ganymede (3.4) and a Subversion shared Eclipse project. Currently ReviewClipse supports only Subversion, but we are working hardly to support several versioning systems in the near future. It doesn’t matter if you are using Subversive or Subclipse as Subversion client, both of them will work without problems.

Install ReviewClipse by opening the Software Updates dialog in Eclipse, and add the following site to your available update sites:

http://www.inso.tuwien.ac.at/projects/reviewclipse/update-site

Reveal the update-site and select the ReviewClipse feature and the appropriate Subversion adapter depending on the used Subversion client:

 
Go to Install… and follow the installation instructions. After a restart of the Workbench ReviewClipse should be installed and working properly.

Configuring Reviews

The review-configuration for a project is created with a wizard within a few minutes. Each developer (author) may have one or several reviewers assigned. If the author commits his  changes to the subversion repository, the reviewers will get a new review-task to review all changes from the revision.

The review wizard is started from the context menu (within the Package- or Project-Explorer) of the subversion shared project. Open Review -  Review Project… and go the the next page. To keep things as simple as possible ReviewClipse fetches all Subversion users from the repository. So there is no need to setup authors or reviewers, because these users should already be identified within your repository.

Having discovered all Subversion users we switch to the next page of the wizard, where we setup the assignments for the reviews. Each author can have one or several reviewers, and each reviewer can be assigned to several authors. So there are several possible scenarios:

• The developers reviews among themselves
• A master reviewer (e.a. technical leader, senior developer) reviews all other developers
• Hyprid approach, where developers and a master reviewer make(s) the reviews

It’s up to you how you make your reviews. In our example we took the third approach, the developers are reviewing among each other’s Java files, and the less skilled developer ben is beeing reviewed by the senior developer chris to look for anomalies and to enforce coding standards. The last assignment has no filter set, because we want to see the changes of all files.

Once the review wizard has been finished, a review file is created within the Eclipse project, which should be commited to share the review configuration with all users.

Doing Reviews

For the majority of inspection tools reviews have to be created manually by a responsible person (e.a. the project lead) by creating the review task, assigning the author and possible reviewers, and attaching some files (the items under review) from the local file-system or a versioning-system. ReviewClipse takes a different, more lightweight approach: Each reviewer subscribes to changes from one or several authors. If an author makes a commit to the Subversion respository, the reviewer gets a new review task within the review editor. Based on the changeset the reviewer makes the code-review and writes some comments for the original author of the changeset.

The reviews are done with a special review editor. This editor shows all outstanding and done reviews for a user. To see the review editor in action we open it with the context menu of the project Review – Open Review Editor. The first time you open the editor a dialog may be opened to identify the current user with an author/reviewer:

In our case we use chris for the reviews. The title area displays the current user. On the right corner of the title area we have an action which searches for new changesets, which means new review-work for me or another reviewer. The upper table shows all changesets under review. A changeset is relevant for the current user if he is the author or the reviewer of the changeset (also indicated by the icon in the second column).

The lower, left part of the editor shows all changed files from the selected changeset. A file may be compared with the previous version, or it may be opened for the selected revision. A reviewer will be interested in comparing the file with the previous version, but if the file has been added in the selected revision it’s only possible to review this version.

The lower, right part of the editor is used to write a review comment for the author of the changeset. The changeset is also rated with Passed, Warning or Failed, depending on the severity of any errors  found. The review comment is only editable for changesets where the current user is assigned as reviewer. In the screenshot above the currently selected changeset has been reviewed and rated as Failed because the author has forgotten some Javadoc comments in a file.

If we save our reviews by closing the editor and commit the review-files, the original author will get the comments to make the necessary re-work.

Conclusion

The flexible design allows to use different types of review models, whichever fits best into your software engineering process. The assignments may be done in a peer to peer manner, where the developers inspect the code changes of one or more team members. Reading each other’s code has the consequence that developers get to know their colleagues' code, thus supporting collective code ownership. As a result, better code sharing and reuse will be more likely, the team's interaction and creativity will be encouraged.

Credits

ReviewClipse - Eclipse integrated Code Review Plug-in.

Mario Bernhart, Christoph Mayerhofer, Thomas Grechenig
Industrial Software (INSO), Vienna University of Technology, 2008.