Tech Review - Agile Code Reviews with Jupiter

Source: Christopher Grant


Code reviews are a valuable part of any software development effort. Agile development processes provide the opportunity to integrate reviews closer to the actual development .

Jupiter

Jupiter is a plugin for the eclipse platform that enables developers to communicate over specific lines of code. The plugin comes with a suggested process for code reviews. The process suggests a three phase approach starting with inspecting the code and logging review items.  A quick demo of this process can be viewed here. When a section of code raises quality concerns, the reviewer notes the issue in Jupiter for later discussion. Once the initial review is completed, the process moves into the second phase which is to discuss the items that were identified. As each item is approved for rework it is updated and assigned to a developer. In the third phase, the developer works through the list of issues that were assigned to him. This process can be used in agile code reviews as well.

Agile

A quick review of the agile development cycle. Code is developed in time boxed chunks called sprints, or iterations. One or more iterations of code are sent to production at regular intervals. We’ll call this the release. For this discussion our release will contain two iterations. In each iteration a developer works multiple story cards to completion then hands it off for various sign-offs.

Agile Jupiter

To integrate code reviews into the process we need to add a step to the story card process. When a developer has completed work, he passes the code to a reviewer.

Individual Review

This reviewer picks up the standard code review process, discussed earlier, starting with the identification of quality concerns. When this individual review is complete the results are passed back to the developer for discussion.

Team Review

In this second phase, the developer walks through the list with the reviewer to understand what the concerns. The two discuss and agree on which items need to be corrected before the story can be signed off.

Rework

Once the list has been discussed and review items have been approved for rework, the developer moves into phase three, to rework the issues found.

Code Review Cleanup

Each code review will generate a series of files that are used by the Jupiter system. A file is created for each developer in each review. Given that a single iteration will contain multiple stories, the result is a handful of files that would need to be managed.
In each review there may be review concerns which will be deferred to a later point. To manage these concerns it is suggested that those issues be moved to a master list or logged as stories for future work.
It is suggested that these code review files be closed down and cleaned up before starting the next release. To close out the code reviews for a release, all outstanding review items should be moved to a consolidated location. What remains are Jupiter files with closed out review items. At this point all Jupiter files can be removed and the review process can be prepped for the next release.
This should be completed after cutting the release. This leaves all review files available to be included in version control system for use in future audits.

Adding a second set of eyes to a coding effort can not only improve code quality but also enhance knowledge transfer within a team. Integrating a code review process into your agile environment can enable those discussions and improve application quality.