Having headaches on different coding style, different developer IQ level and skills, dependence on a single person for a task or tasks, individualism and disunity of the team. Apparently, your project is going through a road to failure. To prevent being dependent on people who has the only key and having to decrypt your source code which was supposed to be simple and readable then this review is the pill to your worries, or might I say the key, 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 properly 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.

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 toin 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.

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.

There are a few useful rules of thumb that are helpful:

1. 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.
2. 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.
3. 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.
4. 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 unfamiliar language? A programmer who is doing something for the first time is most likely to introduce errors.
5. 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 itand will be able to maintain it if it does have problems.
6. 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.”

This entry was posted on Friday, October 31st, 2008 at 7:07 pm and is filed under Reviews.