Page 96 -

There are a few useful rules of thumb that are helpful:
• Is there is a portion of the software that only one person has the expertise to maintain?
That may be a good candidate for review, for two reasons. First, because the rest of the
team will learn how to maintain it; second, it’s only ever been looked at by one person,
so nobody else has yet had a chance to catch any defects in it.
• Does the software implement a highly abstract or tricky algorithm? The more difficult the
algorithm, the more likely it is that a programmer introduced errors in its implementation.
• Is there an object, library, or API that is particularly difficult to work with? Working
with a nonintuitive interface causes many programmers to make mistakes.
• Was the code written by someone who is inexperienced or has not written that kind of
code before? Does it employ a new programming technique? Is it written in an unfamil-
iar language? A programmer who is doing something for the first time is most likely to
introduce errors.

• Is there an area of the code that will be especially catastrophic if there are defects? A
core tax accounting function is more important than the code that renders the splash
screen. Select code that must not fail so that more people can look at it—and will be
able to maintain it if it does have problems.
It is important to select a sample of code that an inspection team can review in about two
hours. The project manager should try to keep the meeting to two hours or less, to avoid
“meeting fatigue.”

Hold the Review Session
The team selection and preparation in a code review are similar to any other kind of
inspection. An inspection team of 3 to 10 people must be selected. Each of these people
must be technically capable of reading and understanding the code being reviewed. Before
the meeting, the moderator distributes the code sample to each inspector, who does indi-
vidual preparation exactly as in the inspection.

The main difference between a code review and any other kind of inspection is in the
review session. While the code review session is similar to the inspection meeting (see

“Page-by-page review” above), there are a few important differences.
In addition to the moderator, there is a code reader who reads the code aloud during the
meeting. The code reader can also be one of the inspectors; the only requirement is that
the reader must have enough technical expertise to understand the code. The purpose of
the reader is simply to keep the team’s place during the inspection; the team should have
already read the code and identified defects during their preparation. Since code is usually
organized in logical units or blocks, it is more useful for a reader to go through those,
rather than having the moderator go through the document page by page.

The reader starts at the beginning of the code sample and announces the first block or log-
ical unit. She does not literally read the commands in the code; she simply gives a brief
description (about one sentence) of the purpose of that block. If anyone (including the

88 CHAPTER FIVE