The Power of Code Review

Reviewing code written by others is hard, and yet it is one of the fundamental aspects of the Mozilla code process. Matthew Gertner recently posted about how he instituted a review requirement as part of the AllPeers development process, and asks some interesting questions about how reviews should be done.

What are reviews for? The primary goal of code reviews is to ensure
code correctness and quality:

For the most part, reviewers are not responsible for ensuring correct code function: unit tests are much better suited to that task. What reviewers are responsible for is much more “social”, and typically does not require a detailed line-by-line analysis of the code to perform a review. In many cases, important parts of the review process should happen before a coder starts working on a patch, or after APIs are designed but before implementation.

There are some important side effects of the review process that are also beneficial:

There can’t really be general guidelines on how much time to spend reviewing. Some experienced hackers may spend up to 50% of their time doing reviews (I typically spend two days a week doing design and code reviews and various planning tasks). This can be hard, because coding feels much more productive than reviewing.

Atom Feed for Comments One Response to “The Power of Code Review”

  1. Jim Plush Says:

    I’m going to forward this post to my team. I was going to write something similar up for our new code review process but you hit on almost all the points I was going to make. Especially:

    “Integration review. Does this code work properly with other modules? Is it localized properly? Does it have server dependencies? Does it have user documentation?”

    I believe it helps keep the knowledge broad, brings up the level of code (since you know people will be scoping it) and decreases brittleness of the code base.

Leave a Reply