What is a code review ?
Filed Under Techniques, Benefits, Review, Improvement, Terms, Development, Process, Software | Posted on October 4, 2007
For many types of work it is standard practice to have one’s work checked by another before the work product is put into service. Engineers have inspectors, writers have editors, and so on. But in software development it is common for code to flow directly from the programmer’s fingertips into the hands of the end users without ever having been seen by another pair of eyes. This has the potential to lead to a number of defects that are only found either during testing or during end customer use. However, if there was a code review, these could have been found much earlier and at much less cost.
A code review is a special kind of inspection in which the team examines a sample of code and fixes any defects in it. Code review is systematic examination (often as peer review) of computer source code intended to find and fix mistakes overlooked in the initial development phase, improving overall quality of software and can also be used as a tool to better develop skills at the same time.
Code reviews have two purposes. Their first purpose is to make sure that the code that is being produced has sufficient quality to be released. In other words, it’s the acid test for whether the code should be promoted to the next step in the process. Code reviews are very effective at finding errors of all types, including those caused by poor structure, those that don’t match business process, and also those simple omissions. That’s why they are an effective litmus test for the quality of the code.
The second purpose is as a teaching tool to help developers learn when and how to apply techniques to improve code quality, consistency, and maintainability. Through thoughtfully evaluating code on a recurring basis, developers have the opportunity to learn different and potentially better ways of coding.
Some core review facts:
1. Using two reviewers is as effective as using four or more.
2. Using an asynchronous process is as effective as a meeting based process for code reviews. For design reviews a meeting based approach may be more effective.
3. One review session is as effective as multiple inspection sessions.
4. Scenario or perspective based reviews are more effective than add-hoc and check-list based reviews.
5. Inspections are effective.
6. Inspecting upstream process like requirements and designs is very effective.
Difference between code review and any other kind of 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.
Code review practices often fall into two main categories: formal code review and lightweight code review.
Formal code review, such as a Fagan inspection, involves a careful and detailed process with multiple participants and multiple phases. Formal code reviews are the older, traditional method of review, in which software developers attend a series of meetings and review code line by line, usually using printed copies of the material. Formal inspections are extremely thorough and have been proven effective at finding defects in the code under review. However, some criticize formal reviews as taking too long to be practical.
Lightweight code review typically requires less overhead than formal code inspections, though it can be equally effective when done properly. Lightweight reviews are often conducted as part of the normal development process:
* Over-the-shoulder – One developer looks over the author’s shoulder as the latter walks through the code.
* Email pass-around – Source code management system emails code to reviewers automatically after checkin is made.
* Pair Programming – Two authors develop code together at the same workstation, such as is common in Extreme Programming.
* Tool-assisted code review – Authors and reviewers use specialized tools designed for peer code review. Programmers often find tool-assisted code review to be less tedious and more efficient than some other methods.
Leave a Reply
