Browse DevX
Sign up for e-mail newsletters from DevX


Peer Code Reviews Made Easy with Eclipse Plug-In : Page 4

Code reviews are a cost-efficient way to detect defects early and improve both the quality of your code and the skills of your team. Jupiter is an innovative Eclipse plug-in designed to make collaborative code reviews much easier.


Phase 3: Team Reviews

The team review phase involves getting the review team (including the author) together to discuss the issues raised during the individual reviews. Typically, the team will work on one workstation, using an overhead projector to display the screen in a meeting, for example, or just working around the same machine if the review team is small enough. The team review involves going through all the issues raised and making a joint decision on the action to take.

To start a team review, just select the Team Phase item in the Jupiter menu (see Figure 11). You then select the project, review, and reviewer ID in the Review ID Selection, as you did for the Individual Review Phase (see Figure 7).

Click to enlarge

Figure 11. Initiating a Team Review

Now the Review Table will display all the issues raised by the individual reviewers (see Figure 12). The details of the selected issue are displayed in the Review Editor (see Figure 13).

Click to enlarge

Figure 12. Conducting a Team Review

Click to enlarge

Figure 13. The Team Review Editor Window

You should go through each issue, discuss it with the review team members, and come to an agreement on the following:

  • What should be done about this issue? Is it really an issue? This is recorded in the Resolutionfield, which can be one of the following:
  • Valid needs fixing (a real issue that needs to be fixed)
  • Valid fix later (a real issue that you won't fix right away)
  • Valid duplicate (such a real issue that it's already been mentioned)
  • Valid won't fix (a real issue that you don't want to fix)
  • Invalid won't fix ("it ain't broke, don't fix it!")
  • Unsure validity (needs further investigation)
  • Who should this issue be assigned to (the Assigned To field)? By default, this is the code author, but it can be changed if someone with specialist knowledge has to intervene, for example.
  • What needs to go in the annotation field, which can be used to note any complementary information that came out of the review discussion?
  • What is the type and severity of each issue? Check the type and severity fields in the Individual Phase tab, and make sure everyone agrees with them.

At the end of the team review, the updated review files are committed to the configuration management system, so that all team members can recuperate the changes and get to work on the corrections. This is done in the next phase, Rework.

The team review phase may not suit all organizations. In practice, team review meetings may be difficult to organize for all but the most strategic classes. You'll often find the bulk of the added value during the individual review phase, and the team review phase may be harder to justify. And while it is not too difficult to convince developers to perform individual code reviews, team reviews can be much harder to put into place.

Indeed, open source projects manage quite well by skipping the team review phase and going directly to the rework phase. In open source projects, physical meetings are often impractical simply because team members tend to be distributed all over the world. In practice, they combine the individual and team reviews into one phase, with a single reviewer.

Another possibility is to maintain teams of several reviewers but combine the individual and team phases. In this approach, each reviewer fills in both the Individual phase and Team phasetabs in the Review Editor. This allows several reviewers to review the same code, but avoids the overhead of organizing a review meeting for each and every code review.

Thanks for your registration, follow us on our social networks to keep up-to-date