William Gladstone once mused that "the heated mind resents the chill touch
and relentless scrutiny of logic". This observation seems to apply remarkably
well to the situations frequently faced by technical code reviewers. Why make
this chore painful, when it can actually be fun, and beneficial to the team!
Using formal code "walk-thrus", especially when multiple team members are
encouraged to participate, can have an incredibly positive effect on the system
construction process. Some of the advantages of performing these peer level code
walk-thrus are:
- Helps to identify "hidden" logic problems before testing even begins.
- Verifies that all of the business requirements have been successfully built
into the program.
- Creates a learning atmosphere for entry level programmers to discuss "best
practices" with more experienced coders and reviewers.
- Promotes consistent programming approaches throughout the system.
- Increases the level of program completeness and quality which put into
program, simply because the programmer's peers will be involved in the review.
- Allows less experienced programmers to share fresh new ideas and approaches
with the more senior team members (upward learning!).
- Creates another opportunity to spot module and class sharing
opportunities.
One of the critical activities which should be undertaken before the first
walk-thru is conducted is to determine the high-level objectives of the entire
process. Answers should be formulated to the following question: Why are we
doing this and what do we expect to get out of this process? The team must
establish the quality checkpoints that will be at the heart of the code
walk-thru reviews. Listed below are a representative sample of some of these
quality objectives:
- Each program follows all established company coding standards.
- Each program follows all unique project coding standards.
- Each program follows any common system "coding patterns" which may not be a
part of the formal company or project standards.
- Each program accomplishes its intended business purpose in as straight
forward and comprehensible a fashion as possible.
- All module or class sharing opportunities are utilized to the maximum
advantage.
- No logic errors exist within any of the reviewed programs.
- All program branches are tied to business requirements.
- Each program is structured and modularized appropriately.
Once the walk-thru objectives have been put into place, and freshly compiled
programs produced, the fun part begins! Pulling a group together to review the
code! But who should be involved in the program "walk-thru"? And how many
reviewers is the optimum number to be involved in the session? These questions
have been the subjects of books, papers, and studies for years. Three to four
people seems to be the optimum number and the following roles should be
filled:
Programmer
Since the programmer actually wrote the code (or action diagrams), clearly he
or she should be involved in the walk-thru. During this review, the programmer
is responsible for stepping the group through the logic within the program,
stopping every now and then to highlight a particularly complex or unclear set
of statements. He or she should be seeking feedback from the other participants
which verifies that all established quality checkpoints are being met and that
any improvement opportunities are not overlooked.
Specification Analyst
If the programmer was not involved into the creation of the specifications he
or she is coding from, the responsible specification analyst should also
participate in the review session. His or her role should be to ensure that all
of the specifications have been successfully transformed into code which is both
efficient and structured, as well as being an accurate translation.
Technical Specialist
Depending on the overall experience of the programmer and the amount of time
he or she has spent on the development application at hand, it may be helpful to
have someone sit in the walk-thru who is very familiar with the languages, as
well as the coding approaches, being utilized by the team. His or her role is to
act as a technical consultant, answering any questions or advising based on
experience, as various programming solutions are discussed. In addition, if
specialized technical coding is required, the technical specialist is present to
assist in this effort and to ensure the correct approach is being taken.
Programming Team Leader
The role of the team leader in this walk-thru is about the same as it was in
the design walk-thrus. Making decisions, ensuring consistency, pointing out
module or class sharing opportunities, and keeping the session focused are all
familiar responsibilities. Again, the team leader should keep the spirit of the
review a quest for quality rather than a critique of the programmer's thinking.
If the programmer is somewhat inexperienced, the team leader should strive to
keep the review non-threatening and educational. This is a chance for the new
programmer to benefit from the experiences of others.
