Tech Review - Agile Code Reviews with Jupiter
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 .
JupiterJupiter 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.
AgileA 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 JupiterTo 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.
Team ReviewIn 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.
ReworkOnce 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 CleanupEach 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.