Formal Approach to Code Review
This is the second article in a series of articles that describe the whys and hows of the code review process. In this part, we will have a look at the Formal code review process. You can also read the introductory article: EFFECTIVE CODE REVIEW: Uprooting Source Code Defects
Formal code review is a detailed process that involves several participants and several stages. This method implies that participants will attend a series of meetings and review code line by line. Generally, reviewers use printed copies of source code. Formal inspections are effective at finding defects in the code under review.
Michael Fagan was the person who first introduced the “Inspections” term over forty years ago. It has been shown that inspections are extremely effective in detecting defects and to be relatively economical compared to testing. The effectiveness of inspections has been proven through a large number of experiments and industrial case studies. Fagan’s article — «Design and Code Inspections to Reduce Errors in Program Development» was published in IBM Systems Journal (Volume: 15, Issue3) in 1976.
Michael E. Fagan was a Senior Technical Staff Member at the IBM Corporation, the Thomas J. Watson Research Center, Yorktown Heights, New York. While at IBM, he has had much interesting management and technical assignments in the fields of software development, engineering, research, and manufacturing. In 1972, Michael created the software inspection process, and has helped implement it within IBM and also promoted its use in the software industry. For this and other work, he has received IBM Outstanding Contribution and Corporate Achievement Awards.
Fagan’s work states that during the inspection, it is possible to find from 60 to 90 percent of all defects and that the feedback obtained from the inspections is prove useful in helping programmers avoid making the same mistakes.
The Process
Inspections usually involve four or more people and consist of several phases. These phases are described below:
Introduction
At this stage, participants are acquainted with a general overview of the area being addressed.
Preparation
Individual participants try to understand the artifact under inspection.
Group inspection
Participants get together as a group and attempt to find as many defects as possible.
Rework
Moderator assigns defects to someone, usually the author, for the fix. The assignee resolves each defect on the list.
Follow-up
Moderator verifies that all rework assigned during the inspection is completed. Depending on the number of defects found and the severity of those errors, you might follow up by having the reviewers re-inspect the entire work product, having the reviewers re-inspect only the fixes, or allowing the author to complete the fixes without any follow-up.
From its initial use as a code-based technique, inspections are now applied to a wide range of document types including requirements and designs documents. In one way or another, any type of review supposes reading programming code. However, there is a difference between an ordinary code review and a code inspection:
- The inspection is targeted on defect detection but not correction or improvement.
- Reviewers with the help of checklists focus extensively on code parts that have been an issue in the past.
- Reviewers have their own role.
- Reviewers prepare for the inspection meeting beforehand.
- The inspection moderator can not the author of the code under review.
Participants’ Roles
One of the key points of an inspection is that each participant has a distinct role to play. These roles are described below:
Moderator
The key person in a successful inspection. They must be an experienced programmer but need not be a technical expert on the program or code under inspection. To preserve objectivity and to increase the integrity of the inspection, it is usually advantageous to use a moderator from an unrelated project.
The moderator must manage the inspection team and offer leadership. Hence, they must use personal sensitivity, tact, and drive in balanced measure. Their use of the strengths of team members should produce a synergistic effect larger than their number. The duties also include scheduling suitable meeting places, reporting inspection results within one day, and follow-up on rework. For best results, the moderator might be specially trained.
Effective management requires that the moderator possesses the following competencies:
Knowledge — refers to what the moderator knows about how to manage the code review process.
Performance — refers to what the moderator is able to do or accomplish while applying their management knowledge.
Personal — refers to how the moderator behaves when performing the review. Personal effectiveness encompasses attitudes, core personality characteristics, and leadership, which provides the ability to guide the team while achieving review objectives and balancing the review constraints.
Program Designer or Architect
The programmer responsible for producing the program design.
Developer or Coder
The programmer responsible for translating the design into code.
Tester
The programmer responsible for writing or executing test cases or otherwise testing the application.
Four people comprise a well-sized review team, although circumstances may prescribe otherwise. If the code is involved in a number of interfaces, the programmers of code related to these interfaces may profitably be involved in the inspection.
Scheduling inspections
It is advisable to schedule inspection sessions of no more than two hours at a time. As practice shows, the error detection efficiency of most inspection teams tends to decrease after two hours of inspection but then grows up after a period of different activity. Two two-hour sessions per day are acceptable. It is important to schedule the time to conduct inspections and resulting rework
Inspection Process
Overview
The designer first describes the overall area being addressed and then the specific area he has designed in detail — logic, paths, dependencies, etc. Documentation of design is distributed to all inspection participants on the conclusion of the overview.
Preparation
Participants use the design documentation, literally do their homework to try to understand the design, its intent, and logic. Sometimes errors are found during this operation, but in general, the number of errors found is not nearly as high as in the inspection operation. To increase their error detection in the inspection, the inspection team should first study the ranked distributions of error types found by recent inspections. This study will prompt them to concentrate on the most fruitful areas. Checklists of clues on finding these errors should also be studied.
Inspection
All participants in the inspection group get together. The moderator controls the meeting, making sure that it stays focused so that it does not get out of hand or stray off course. All related documentation should be available during the inspection. With the design of the artifact under inspection understood (in the previous preparation phase), the main objective in this phase is to find defects. This occurs as the “reader”, chosen by the moderator (usually the coder) takes the team through the inspection artifact. Once a defect is found, no attempt should be made by the inspectors to find a solution. Defects are noted by one of the group members given the task of being meeting scribe (either the tester or someone with no other task).
Conclusion
The formal approach requires strict review criteria (e.g., in-person meetings and reviewer checklists) to ensure a base level of review quality, while the modern, lightweight code reviewing process does not.
