Code Review

Code review is a process to ensure that bugs and errors are caught and fixed before they reach production. This very often requires the participation of developers who are not directly involved in implementing the particular part of code that is being reviewed. Code review is part of a bigger quality assurance process to ensure that the final product performs exactly as expected.

Apart from checking source code for bugs, code review is a great way to check the code base for the presence of best practices and the absence of anti-patterns.

Why does code review matter?

People often have different opinions on all sorts of things, especially when it comes to code, and that is totally OK! But when it comes to the codebase used in a production application, you will want to ensure that all developers on the team speak the same language regarding naming policies or architecture patterns.

Why does this matter? Imagine two developers, Alice and Bob, writing an app together. Alice loves using a global singleton string, also known as the Singleton pattern, for state management, while Bob prefers using the State pattern. They work on different parts of the application committing their changes directly to the shared repo.

Then Alice leaves the project for a few weeks on vacation, and now Bob has to fix a bug in a feature she implemented. He sees the global singleton string and, confused, changes it to the State pattern implementation, just as he did with all of the features he has implemented before.

Unfortunately, doing so requires twice as much time to fix the bug, so Bob quickly becomes annoyed and disappointed.

Had they implemented a code review process from the beginning, Alice and Bob would have identified variances in style much sooner. What they needed was a collaborative workflow that made sense for both parties.

What should a code review cover?

Let’s look into the basic outline of what a successful code review should cover and what elements of the code the reviewer should be paying close attention to.

When performing a code review, the person reviewing the code should focus on the following:

Repercussions of No Code Review

Why is code review so important? What will happen if there is no code review or too much code review?

1. The potential to introduce high-risk bugs.

Code Review is primarily intended to find bugs in code. If there is too little code review, or no code review at all, some bugs will likely pass to production unnoticed. Bugs can cause low-risks, like faulty UI, or high-risks, like security breaches. Without code review, the team has very few instruments to predict and evaluate such risks.

2. Inconsistent codebase.

As in the example with Alice and Bob, people tend to prefer different patterns and code styles and may use different approaches to state management. The difference in approaches may slow down further development and code support. Every time you need to implement something new or fix a bug, the developer will have to take the time and mental energy to learn a new process, further slowing the process.

3. Bus factor.

Bus factor refers to the risk measurement associated with not sharing information and capabilities among team members.

So, if only one person knows how a specific part of the project works— the one who wrote it—and said person leaves the project, you will probably have to perform another code review, or even rewrite the code all together.

Too Much Code Review

When it comes to having too much code review, there are very few risks associated, but there are a few cons, so to speak. Having an abundance of code review can cause delays in production and may cause developers to focus too much on satisfying the code review, rather than fulfilling high-level business goals.

At the end of the day, it’s important to find a golden median. Evaluate the risks associated with limiting code review if you have to prioritize faster code production.

Code Review Checklist

Code review is, above all, a communication process. And like any other, everyone involved should feel respected for the process to be efficient. So there are some simple rules to follow to make your code review helpful and nice, while also providing useful feedback.

If you are the person performing the review, consider the following code review checklist:

1. Explain your opinion.

When pointing to an error, add a bit of explanation about why you think this should be viewed as a mistake. This will make you sound confident and will also help the code’s author to not make similar mistakes in the future.

On the other hand, it could be you who is wrong. Explaining where you’re coming from will help encourage a discussion to find the best solution if there are any variances in opinion.

2. Include examples.

Sometimes, it’s hard to understand a message like: “change it according to the guidelines”‘ or “use the X pattern.” What might be obvious to you could be a complete riddle for someone else.

Give a brief example of what the final result should look like in your opinion to help the author understand your idea.

3. Point out specific problems.

“I don’t know what’s wrong with this code, but you can do better” isn’t very helpful. Tell the code’s author exactly what’s causing the issue. Is it memory management? Is it code style?

Make sure to provide helpful details, particularly if the resolution will require further investigation by the author. Most of the time, when code isn’t provided in a satisfactory state, the better solution doesn’t just pop into the reviewer’s mind. It’s OK to request further investigation by the author, but you should provide some direction.

Code Review Tips

People work more efficiently when cooperating. “Two heads are better than one,” right? This is precisely the reason why, as a reviewer, you should try and sound friendly. Maintaining a cooperative tone of voice helps the team concentrate on solving the issue at hand, instead of escalating conflicts.

Here are some code review tips on tone of voice: