Implementation

During the implementation, or coding stage of a software development project, software engineers complete detailed level designs and write code. One of the key processes level three organizations complete during the implementation stage is peer reviews. During a peer review, a group of developers will meet to review a software module, including the code under development, the detailed design, and the requirements of the module. To someone who is not a software developer, getting a half dozen people in a room to review, line by line, hundreds of lines of code in a software module may seem like a large waste of time. In reality, however, code reviews are one of the common processes followed by successful software development organizations of all kinds. Here is the outline for a sample code review:

Attendees

We typically try to have between four to eight code reviewers (peers of the developer) from the same or related application development teams . The developer's manager attends if possible. We typically try to involve a system architect or senior developer as a facilitator for the code review.

Ground Rules

We have found that these ground rules are essential to making a code review productive. We always review the ground rules at the start of each code review.

No grading. The purpose of the code review is not to grade or otherwise measure the performance of a developer, but to identify and resolve any issues while the code is still under development. Unless this is perfectly understood and practiced, we often find a developer's peers are unwilling to raise issues with code in front of a manager or more senior developer for fear of having a negative impact on the developer. This dilutes the entire value of the code review.
No incomplete phrases. During the review, incomplete phrases are typically well understood by all given their context. However, two weeks later, a developer will typically not be able to understand the meaning of an incomplete phrase noted in the meeting minutes. When everyone speaks and writes in complete sentences, it makes follow-up on the review much simpler.
Majority rules. Everyone must agree up front that when issues are raised, they will be discussed until everyone is in agreement. This is a peer review by developers working on the same or closely related applications. If there is any question as to the validity of the design or of a code segment, this is the time to resolve it. If there is not 100 percent agreement, then those in the minority must ultimately, if they cannot sway others to their case, side with the majority view.
Stay intellectually committed. It takes a lot of effort to follow, line by line, the code of another developer. However, everyone in the code review is making a major investment in the review for the benefit of the entire team. Everyone needs to be 100 percent committed to the review process and not duck what they perceive are issues.

Requirements Review

The developer presents the requirements that have been allocated to the module.

Design Review

The developer presents the detailed design of the module. Visual aids used include flow charts , UML diagrams, call graph trees, class hierarchies, and user interface components .

Code Review

At this point, the facilitator takes over and walks everyone through the code. This frees the developer to concentrate on listening to and documenting comments made by the reviewers.

Summary

The findings of the code review are summarized by the facilitator. If necessary, specific design modifications are agreed to. If major design changes are required, a follow-up code review will always be conducted . If only minor code changes are identified, no follow-up review will typically be required.