Guide to peer reviews

A peer review, sometimes known as a code review or walkthrough, is a thorough technical and logical line-by-line review of a code module (program, subroutine, object, method, etc.). During a peer review, code is inspected to identify possible improvements and ensure that business requirements are met. If necessary, a meeting is held to discuss any issues that come out of the review process.

Although some programmers complain that the reviews take too much time, the drawbacks are usually outweighed by the benefits, such as fewer bugs, less rework, more pride, and better team communication and cohesiveness.

How does it work?
Peer review methodologies are as numerous as the companies that write code, but most follow a basic three-step model consisting of preparation, review, and follow-up. Here's a look at each step.

Preparation
First, the code being reviewed must be complete, tested by the programmer, and in the programmer's view, ready for the next step in the development life cycle. The code and other affected project components, such as documentation, test cases, a project schedule, or requirements changes must also be available to the review participants. Participants should review the code and other materials prior to the meeting and come prepared to discuss their issues without having to read the material again during the meeting. Of course, the date, time, and location of the meeting should be established in advance.

Review
Reviews are conducted as needed, usually based on the rate of code output. The frequency of individual participation in a peer review depends primarily on the size of the programming team. A team of three programmers might include all three in every review. Larger teams might be able to rotate participation based on experience, skill level, subject matter familiarity, or site-unique factors.

If possible, the review should include the programmer, two reviewers, a recorder, and a leader. Still, even if only one other programmer can review code, he or she should do so. Other considerations for the size of the review team might be the scope of the project, workload, or training needs.

Some questions reviewers might bring upââ,¬"and which the programmer must be ready to discussââ,¬"include the following:

• How does this module actually satisfy the stated business requirement?
• Wouldn't a case statement work here instead of a nested if-then-else structure?
• How does the output affect the previously base-lined interface documentation?

All participants should be open-minded and willing to discuss issues in a straightforward manner. The programmer needs to recognise that the suggested changes are not personal attacks, and the reviewers need to recognise the programmer's pride of authorship. The team leader has the authority to decide which suggestions will be implemented. The leader also uses the meeting to stay involved and aware of what the team members are doing. Someone should be designated to document the proceedings.