Parasoft Logo Register | Log in  /  Contact us  /  Blog  /  Support  /  Downloads  /  /  888-305-0041  /  Language »
For a Printable Version, click here (547 KB PDF).
Download the latest version of Adobe Acrobat if you do not have a PDF reader.

Code Review Best Practices

Peer Code Review, Automated Code Review

This paper is part of a series of interviews in which Adam Kolawa—Parasoft CEO and Automated Defect Prevention: Best Practices in Software Management (Wiley-IEEE, 2007) co-author—discusses why, when, and how to apply essential software verification methods. The series also addresses code analysis, unit testing, memory error detection, message/protocol testing, functional testing, and load testing.

In this interview, Kolawa discusses why, when, and how to implement peer code reviews (code inspections). Read on to learn how process automation plus a focus on requirements can help your team uncover more complex defects without impeding project progress.

Different people mean different things by code review. What’s your definition of code review?

First off, I think that the only practical peer code review process—for centrally-located teams as well as geographically-distributed ones—is one that that’s managed automatically. For example, using Parasoft’s Code Review module:

  1. Developers check in code to the source code repository as normal.
  2. A server-driven code review scanner automatically detects what code needs to be reviewed, generates code review packages that show the difference between the new code and the old code, and automatically notifies the designated reviewer(s) that a review is needed.

  3. Reviews are performed at each reviewer’s convenience from his familiar IDE (Eclipse, Visual Studio, RAD, Wind River Workbench, ARM RVDS, etc.).
  4. After examining each change, the reviewer either accepts it or requests additional revisions.
  5. If additional revisions are requested, the author is notified of the request, and the cycle continues.

In a nutshell, that’s how to make the code reviews practical.

To make them effective, they must be tied to requirements, with reviewers focused on determining if the code is actually doing what it’s supposed to be doing. If you don’t do this, the code review typically degenerates into developers scanning the code for problems that automated code analysis could find. That’s a shame because code analysis tools could do this scanning faster, better, and more accurately—and developers could be doing something much more valuable and interesting.

These two things are actually quite closely related: with a computer handling all of the tasks that are not creative, the brain can focus on thinking about the code in terms of the requirements.

Why is this focus on requirements during code review so important?

It’s the best way to identify improperly-implemented requirements—one of the three main categories of defects (along with missing requirements and poorly-designed interfaces that allow users to wander in unintended directions). With at least one other person inspecting the code and thinking about it in context of the requirements, you gain a very good assessment of whether the code is really doing what it’s supposed to. Automated analysis simply cannot uncover these algorithmic functional issues—this high-level analysis requires a human brain.

And what’s the value of code review workflow automation? What do you have against a good old-fashioned sit-down code review?

Well, with sit-down code reviews, the cost usually outweighs the benefit. The cost is significantly higher with sit-down code reviews. First, everyone has to figure out a time and place that’s convenient to meet. This is difficult for centrally-located teams, and nearly impossible for many geographically-distributed teams. Then the developers have to spend lots of time on preparation—trying to remember what code was changed and why, marking the changes, correlating the new version and the old version, and so on. Finally, you have all the time required for the review itself.

What’s worse, the benefit is typically lower with sit-down code reviews. They typically uncover fewer problems than automated code reviews do. Why? When everyone is sitting together in a room, they don’t give themselves enough time to really think through the code, identify all the possible problems, and come up with viable solutions. The brain does not work instantly; it needs time to think. That’s why it’s significantly more valuable to have a code review process that allows you to review code at your desktop, at your convenience, with enough time to vet potential problems and determine how to make the code more effective.

How does all this time thinking about the code during code review impact the team’s productivity?

Surprisingly, it actually improves productivity...

To read more, download the complete Code Review Best Practices paper as a PDF.

Google+RSSBlogTwitterFacebookWikipediaLinked InYouTube Copyright © 1996-2014 Parasoft   |  Privacy Policy |  Site Map