Crash Course in Lightweight Code Review

Most programmers agree that another pair of eyes on your code will uncover bugs and disseminate knowledge across development teams. But many also recognize that peer review can waste a lot of time.

So how do you get started in such a way that you 1) don't waste time, 2) match the process to your team and your goals, and 3) have a clear way to evaluate results? So many code review techniques exist, and each with pros and cons, so which are right for your team? Even if you're unwilling to spend the time to review all your code, perhaps spending a little time reviewing a specific subset would be worthwhile.

The only way to know is to try it for yourself. Use these tips to simplify, expedite, and measure the process.

What Is Code Review and How Do You Do It?

First, let's make sure we're on the same page. What is "code review?" The answer varies depending on whom you ask, and when; code review has changed dramatically in recent years.

Thirty years ago, if you wanted a well-known and measurable process that delivered results, your only choice was the dreaded Formal Inspection -- a seven-phase, multi-meeting, paperwork-heavy system popularized by Michael Fagan at IBM. Properly done, it takes over ten person-hours to review at most 200 lines of code -- a sluggish rate that makes this system impractical (not to mention excruciating) even if it does uncover bugs.

In the past 10 years a variety of evidence [1][2][3][4] has shown that many of the components of the traditional "heavyweight" inspection process are inefficient or even unnecessary. "Lightweight" modern code review methods include:

Over-the-Shoulder: The reviewer physically looks over the author's shoulder and is walked through the code.

Email Pass-Around: Code differences are emailed automatically by the version control system. Reviewers respond to changes when they have time.

Pros: Easy to set up, nothing to purchase, works remotely.

Cons: No tracking -- don't know if found defects were fixed, often reviews never happen because everyone assumes someone else looked at it, no metrics; reviews "fizzle out" instead of finishing. Hard to follow conversations as emails get replied to and forwarded among several people.

Tool-Based Review: Use a development tool specifically designed to assist in code review. A variety of open-source and commercial tools exist.

Pros: Removes most of the busywork associated with file-collection, discussion/defect management, and metrics/reporting. Tracks reviews and defects.

Cons: Have to learn and integrate another tool, can cost money.

Pair-Programming: Two developers at the same keyboard and monitor working on the code together.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!