The Value of Code Review – Why, When, & How

During my most recent project, we made extensive use of formal code reviews. This process drastically increased the quality of code in the project, reduced the ramp-up time of new devs on the project, and facilitated knowledge sharing across the entire team. I also found that it didn’t cause an excessive hit on developer productivity for our project.

The Benefits of Code Review

We found a lot of benefits to using code review at all stages of our project.

• In the beginning of our project, doing code review helped us leverage the established code base we were using much more effectively, because we could get feedback from the current developers if we were not leveraging some existing code.
• Later in the project, we had several points where we added new developers to the team. Code review helped reduce the ramp up time for these developers by a lot. Specifically, we were able to let new devs work on their own features with a greater level of confidence, because we could review and offer helpful feedback on any code they wrote before it was merged.
• Code review was also helpful because the team for our project was geographically dispersed. Co-location of teams has a lot of helpful benefits as far as building a collaborative atmosphere where ideas are discussed and developed in real time. While we lost some of that due to not having a co-located team, we were able to get some of these benefits from insightful discussions in code review threads.

Techniques for Effective Code Review

Doing code reviews the wrong way could potentially be a drag on your project. Using the right tools and techniques can prevent you from wasting to much time reviewing, rather than writing, code.

1. Use Feature Branches

This is a good practice in general, but it offers some specific advantages for code review. Feature branches mean you can isolate a set of code that needs review to be only related to a specific feature. Feature branches also allow for quick context switching when code is ready for review. You can switch to a new feature when your current one enters review, and easily switch back if you need to address some feedback in your feature under review.

2. Isolate Reviews to Small Changes

Small change sets take drastically less time to review than large ones. When reviewing a large change set, you are not just looking at more lines of code, but at a larger quantity of interdependent code which you need to comprehend. The result is that the time it takes to effectively review a set of code does not scale linearly to the amount of code changed. Isolating code to be reviewed to small, tightly-knit changes can reduce the mental load on your reviewers and streamline your review process.

3. Use a Tool Designed for Code Review

This may seem like a no-brainer, but it’s really important. Some important features include diff viewing, being able to comment changes line by line, and being notified when code under review is updated. My team used Github to manage our project code, and we used Github’s pull request feature to manage our code reviews.

4. Have a Process for Reviews

Initially, our project didn’t have a formal process for review. We would just open a pull request, wait for someone to choose to review it, and eventually someone would merge the change. This worked out very poorly. Sometimes no one would review a pull request for days, and sometimes someone would merge requests before someone was able to give feedback. Also, some developers ended up taking a much heavier code review load than others. Overall, not having a process made us very inefficient.

We eventually recognized this and created a formal structure for how our code reviews should go, and this streamlined our reviews. A review process should probably cover at least the following points:

1. How reviews are assigned to different people
2. A minimum expected feedback time for reviewers
3. How to indicate that a review is finished
4. Who is responsible for merging code that has finished being reviewed

Should I Use Code Review in My Project?

I think code review can be a good fit for a lot of projects, but it is not a universal solution. Some project situations where code review might be useful are:

• Any time you have 5 or more developers.
• When you are adding new devs to your team.
• When your team isn’t co-located.
• When your project has disparate components that are being developed by different teams.
• When you are still in the stage of developing conventions and best practices for you code base.
• When some of you team has less experience with your current technology stack that others.

Conversely, times when code review will probably not add much additional value to your project include:

Have you used code review in any of you projects? What were your experiences, good or bad?