|
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
which does not properly implement its requirements, which does not
function as the programmer intended, or which 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 uninteresting code that looks very similar to the code already developed
in previous applications, which has a lower risk of containing as many defects.
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 three to ten
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 individual
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 code review session is
similar to the inspection meeting (see “Page-by-page review” above), there are
a few important differences:
- One important difference is that in addition to the moderator,
there is a code reader who reads the code aloud during the meeting. 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.
- Another important difference between code reviews and document
inspections is that the code review is much more focused on detecting
defects, and less on fixing them.
- In the code review, the moderator needs to be especially careful
not to let the meeting turn into a problem-solving session. Programmers
love to solve problems. It’s easy for them to get caught up in a small
detail and turn the meeting into an analysis of a minute problem that
covers just a few lines of code.
The following attributes should be verified during a code
review:
Clarity
- Is the code clear and easy to understand?
- Did the programmer unnecessarily obfuscate any part of
it?
- Can the code be refactored to make it clearer?
Maintainability
- Will other programmers be able to maintain this code?
- Is it well-commented and documented properly?
Accuracy
- Does the code accomplish what it is meant to do?
- If an algorithm is being implemented, is it implemented
correctly?
Reliability and Robustness
- Is the code fault-tolerant? Is it error-tolerant?
- Will it handle abnormal conditions or malformed input?
- Does it fail gracefully if it encounters an unexpected
condition?
Security
- Is the code vulnerable to unauthorized access or
malicious use or modification?
Scalability
- Could the code be a bottleneck that prevents the system
from growing to accommodate increased load, data, users or input?
Reusability
- Could this code be reused in other applications?
- Can it be made more general?
Efficiency
- Does the code make efficient use of memory, CPU cycles,
bandwidth or other system resources?
- Can it be optimized?
|
