How to prepare for effective code reviews: catch more bugs with these best practices

By Yosan | Posted Sep 28, 2017 | 4 min. (831 words)

Code reviews. Two words that can elicit visions of the last hurdle to conquer before one’s hard work is released into production.

For the reviewee, it can also be difficult having work scrutinized, line by line. For the reviewer, it can become a chore lacking direction and process.

However, code reviews don’t have to be something that fills anyone with dread. Here are the three tips for more delightful and effective code reviews.

1. Prepare code reviews

Preparing for the review is the responsibility of the reviewee. Two techniques which ensure more productive reviews are having small pull requests and providing information to the reviewers.

Small pull requests of 200 lines of code or less are the optimal size for catching defects in code reviews. This can be achieved by creating a pull request for one piece of functionality, unit tests, or, for large code changes, only submitting 200 lines of code at a time if possible.

Background information on the pull request goes a long way in giving reviewers context. It could include a description of the feature or bug fix, comments where necessary, and which solution, project or part of the system this code is found in.

2. Choose wisely

In Tekken Tag, you pick two characters you’re strongest with to get the most out of the tournament. Choosing the right code reviewers is similar in that you work as a team to get the best out of the review while learning and enforcing a good work culture.

A good place to start is to have a clear purpose of the review, and then to pick the right team.

Purpose

Most code reviews cover one or a mix of the following four goals:

Reinforce clean code practices
Catch bugs
Knowledge share
Upskill inexperienced developers

Once you have established the goal, the reviewee or team assign the reviewers. Newer members of the team and less experienced developers may need direction on who the reviewer should be.

Reviewers

There are three main types of reviewers. Depending on the above purpose, below is a clear breakdown of the attributes of each type of reviewee and how they relate to the purpose of the review:

Team

Attributes: A small feature team of two to four developers of mixed skills and experience.

If a team needs to share knowledge or upskill, getting the whole team involved is an excellent idea. Each member contributes by asking questions, catching typos and bugs, finding better ways to write code and upkeep in-company style rules.

Being able to ask questions during reviews and having healthy debates on the ‘best way’ lifts the overall skill level of a team. I worked on a small feature team where the whole team jumped on code reviews whenever code was ready. Reviewing code was the #1 way to learn the code base and view clean code techniques in action regularly.

Senior developer

Attributes: ‘Senior’ is a loose term here. This developer should have a high standard of clean code practices, excellent troubleshooting, and bug catching skills, and possibly hold a mentoring role.

A senior developer is suitable to review all four types of code reviews. The final step before shipping code usually lies at the code review. And they take time. A more experienced developer may faster at spotting clean code violations and bugs. The faster this step, the faster it will reach the ‘Done’ column in JIRA.

Senior and second developer

Attributes: Senior with attributes stated above. The other developer, of any skill level, should know the area of code under review well, and possibly be more knowledgeable of the area than the senior dev.

In this tag team, time is cut down by sharing tasks. The senior dev could look at clean code techniques and catch bugs. The second developer could primarily focus on the functionality. There will be overlaps with both developers looking at code techniques and bug catching, but this will help catch most of the issues with two pairs of eyes.

Reviews are a practical way to reinforce a good company culture. Feeling like you’re under scrutiny is never pleasant, but reviews don’t have to feel that way if there’s a healthy company culture. Reviews are an excellent way to get one’s code into tip-top shape – sarcasm and derision have no place in a code review.

3. Have a checklist

Checklists are a great way to include all elements of a code review, without having to remember what to look out for. Every company is different, but here’s a checklist that covers the basics:

The checkbox ‘20 minutes at a time‘ is to help reviewers relax their eyes and come back to the code with a fresh perspective. What better way to catch those pesky typos or bugs!