Page 95 -

These guidelines can help an author lead a successful walkthrough meeting:
• Verify that everyone is present who needs to review the work product. This could
include users, stakeholders, engineering leads, managers, and other interested people.
• Verify that everyone present understands the purpose of the walkthrough meeting and
how the material is going to be presented.

• Describe each section of the material to be covered by the walkthrough.
• Present the material in each section, ensuring that everyone present understands the
material being presented.
• Lead a discussion to identify any missing sections or material.

• Document all issues that are raised by walkthrough attendees.
After the meeting, the author should follow up with individual attendees who may have
had additional information or insights. The document should then be corrected to reflect
any issues that were raised.

NOTE
Additional information on walkthroughs can be found in Peer Reviews in
Software by Karl Wiegers (Addison Wesley, 2002)

Code Reviews

A code review is a special kind of inspection in which the team examines a sample of code
and fixes any defects in it. In a code review, a defect is a block of code that does not prop-
erly implement its requirements, that does not function as the programmer intended, or
that is not incorrect but could be improved (for example, it could be made more readable
or its performance could be improved). In addition to helping teams find and fix bugs,
code reviews are useful for both cross-training programmers on the code being reviewed
and for helping junior developers learn new programming techniques.

Select the Code Sample
The first task in a code review is to select the sample of code to be inspected. It’s impossible

to review every line of code, so the programmers need to be selective about which portion
of the code gets reviewed. Many teams have found that it takes about two hours to review
400 lines of code (in a high-level language such as Java), although this estimate differs
dramatically from team to team and depends on the complexity of the code being
reviewed. At that rate, there is no way a team could review all of the code for a software
project. Nor would the team want to—in any program, there is a good deal of uninterest-
ing code that looks very similar to the code already developed in previous applications,
which has a lower risk of containing as many defects.
The purpose of any inspection is to find and repair defects. Since a relatively small portion
of the code will be reviewed, it’s important to review the code that is most likely to have
defects. This will generally be the most complex, tricky, or involved code.

REVIEWS 87