Who Should Review My Code?
  May 13, 2014

Choosing who to include in a review of your code is an important part of the development process. In larger organizations, you may have code review teams consisting of a manager, a security expert, a few more senior developers and a few younger developers. Less formal teams don’t traditionally have “teams” for code review. They may simply have rules around code review, such as setting how many reviewers must approve the code before the review can complete.

Ultimately, of course, you’ll want to find developers that are quick to respond, and who offer assistance with your code, whether by finding defects or making constructive comments. Here are a few other suggestions for setting up your reviews.

1. Keep Reviews to a Minimal Set of Participants.

Development organizations often want to include many developers in a review. There are two main reasons for this. First,  it allows for more developers to be aware of more of the overall source code – not just the code they are responsible for.

This is true – and a big benefit of code review. Second, some managers believe the more people that review the code, the more defects that will be found in the development process. While both of these are true benefits, it’s also true that having a large number of reviewers can slow down the review process considerably, resulting in more frustrated reviewers – and authors.

Our general recommendation is not to include more than about 10 reviewers. And most organizations can see optimal benefits with even fewer reviewers.

2. Invite “Experts” in Particular Areas to Look for Specific Things in your Code.

Typically, development organizations have areas they want to ensure reviewers are looking at during the review process. The area we hear most often discussed is around security.  In these instances, add the security person to the review.

Getting their blessing on your code during the review process can be incredibly important and save time (and money) in the long run as they find defects in the review process.

3. Invite those more senior to you.

This probably goes without saying, but developers need to add co-workers that have more development experience than they do to the review. This helps the author learn from the comments made and the defects found.

In a great review, reviewers help the author not just by pointing out defects but also by helping them write better, more elegant code or by helping them document their code.

4. Invite those more junior to you.

Equally important to inviting developers more senior to you is to invite those more junior to you. Let the more junior developers learn from those that have been doing this a while.  This is a great way to develop more junior developers – and to improve the quality of the overall development organization.

See also: