Introduction
This document describes the code walkthrough procedure for the GFESuite
team.
Participants
At least two people are required for the code walkthrough:
- Developer - who wrote the code
- Reviewer - who reviews the code
Level/Types of the Code Walkthrough
The level of the code walkthough is determined by the extent of the
code changes to be reviewed. Complexity of the changes,
extent of the changes, and criticality of the changes all play into the
decision of place/location of the code walkthrough. The
Developer makes a recommendation for the appropriate level of the code
walkthrough. The Project Lead may override that
recommendation.
The various level/types of the code walkthrough are:
- Waived: Code walkthrough is waived due to a very simple algorithm
change (or configuration file), and not in a critical point in the code.
- Informal: Code is presented to the reviewer who simply reviews it
"on-the-spot". This is reserved for simple, confined, and
non-critical changes.
- Formal: Code is presented to the reviewer and the reviewer
examines the code and algorithms for proper style, format, and
technique. This is reserved for complex code changes of a
critical nature and those changes that may impact multiple subsystems.
In addition based on the complexity, extent, and criticality of the
changes, as well as the reviewer's knowledge of the design and
implementation, the code walkthrough may be conducted independentally
by the reviewer, rather than have the developer do a presentation or be
present. If the reviewer has questions, then the reviewer is
responsible for seeking out the developer to answer the questions.
Purpose of the Code Walkthrough
The purpose of the code walkthrough is to ensure that the requirements
are met, coding is sound, and all associated documents completed.
Design
Design is presented at the code walkthrough in order for the Reviewer
to understand the context of the software change. Depending upon
the scope of the software change, the design does not need to be
written, but may be presented orally.
Coding
Code is reviewed for the following:
- Clarity and Readability - as in accordance to the coding
standards.
- Requirements Met - code does what it is supposed to do.
- Performance - code is coded to prevent performance problems
- Algorithms and Error Situations - algorithm used is sound, error
conditions handled, all reasonable conditions are handled.
In appropriate cases, the old and new code may be presented in order to
show the differences, if it helps explain the changes.
User Documentation
User documentation, if appropriate, is examined for:
- Existance, for the functionality implemented.
- Clarity and Readability
- Completness - e.g., User, Training, Reference, Table Of Contents
Release Notes
Release note documentation, if appropriate, is examined for:
- Existance, for the functionality implemented.
- Clarity and Readability
Test Plans
Written Test Plans are reviewed, if appropriate, for:
- Existance, for the functionality implemented.
- Completness - for a written test plan to cover the particular
functionality or correction. All reasonable cases are handled.
Automated Test Plans are reviewed, if appropriate, for:
- Existance, for the functionality implemented.
- Completeness - for the various scenarios / use cases to exericse
the software. All reasonable cases are handled.
If the task does not warrent a written or automated test plan, then the
developer is expected to explain how the code has been tested. The
reviewer should check that the code was:
- Exercised, for the functionality implemented.
- Completeness - for the various scenarios / use cases to exericse
the software. All reasonable cases are handled.
Outcome of the Code Walkthrough
There can be three outcomes to the code walkthrough:
- Successful: all required checks and quality are present.
Software may be released into the approved build.
- Corrective Action Needed, No Further Review Needed: a list
of items to be corrected are presented. Once these are performed,
the code walkthrough is complete.
- Corrective Action Needed, Review Needed: a list of items to be
corrected are presented. One these are performed, another code
walkthrough is warrented.
If the code walkthrough was successful, then the software change may be
released into the approved build. Based on the tkgnats
states, the task may be changed from "developed" to "qa" after a
successful code walkthrough.