Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS What Is Code Review and How Do You Do It? Getting Started

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.
  • Pros: Easy to implement, no tools required.
  • Cons: Interrupts reviewers, hard to know which code is reviewed, impossible to measure and track. Requires coordinating with someone else's schedule.

• 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.
  • Pros: Deep level of review; teams know review is happening but it's difficult to track.
  • Cons: Large time investment, some developers dislike it. Requires coordinating with someone else's schedule.

Pick a method that most closely matches the existing culture of the team. Use the pros, cons and amount of time you have to select one and stick with it for one week before you start to make changes.

1 What Is Code Review and How Do You Do It? | 2 Getting Started Next Page

RELATED ARTICLES Logging In C++ : Part 2 OutSystems Updates Agile Platform SDK, .NET Controls Released for Communications Enabling Web Pages Welcome To the World of Cryptographic Voting recls 100% .NET		TOP 5 ARTICLES No Top Articles.