Code Review That Matters: Tips and Best Practices

First of all, what’s a code review? Basically, it’s a review of written code performed by other team members. The result of the code review is feedback on the completed task: change requests and comments or green light for further testing and release.

Even though the task itself seems pretty straightforward, there are many things to take into account and a number of different ways of performing code review, and there is no unified guide that would work for every company or project.

Developers have different styles of writing code, and code review may turn into a battle of preference. Moreover, the code review process cannot speed up your development: it always implies extra time creating pull requests, fixing bugs after the review, and testing the functionality after the fix. 

With all this said, you may think: is the code review even necessary? And the answer is simple: it is. 

In this article, I am going to explain why it is worth investing precious time into code review and will give some recommendations that would help improve the quality of your project through code review and will not harm the relations in the team, but on the contrary, will strengthen collaboration. 

The Value of Code Review

Before we get into detail, let's figure out why code review is crucial for development and why the time and effort spent on setting up the code review process and the developers’ working hours will greatly impact the success of your company.

First of all, more eyes on your code means more chances to catch potential bugs or security or privacy issues. The earlier these issues are identified, the cheaper it is to fix them. 

At this step, fixing a bug means just changing the code and pushing the changes, as opposed to potential production downtime, problems from regulators, or ruined product reputation due to user data leaks.

Code review means sharing best practices within a company or project. This is truly beneficial as it ensures that all developers can follow these rules and write code accordingly, making it concise, clear, and maybe even matching the style. Similarly, knowledge sharing allows developers to share their personal approaches, which can enrich others with new perspectives.

Code review is also relevant for maintaining the correct workflow, such as preventing a developer from making unverified changes directly to production. Properly performed code review minimizes the risk of bugs and additionally serves as a protective layer in case a developer intentionally decides to break the code — even though such cases are unlikely, sometimes they occur.

Best Practices

Now, let’s take a look at some tips that may help you build the process of code review in the most efficient way that will also be beneficial for the teams. 

For a detailed review, it might make sense to check the author's branch on your local machine and examine each modified file individually. Your code editor can help identify syntax errors, and file connections are easier to comprehend when viewed locally. Encourage a focused and thoughtful review. For example, when I need to review the code, I book a time slot in my calendar, put on headphones, and basically ensure that there are no distractions. This helps understand the unfamiliar context properly and stay focused throughout the process.

Sometimes, it makes sense to review just syntax and pick obvious bugs without getting into the whole business logic. Do a deep review if the author specifically asks for it. This approach is useful if you get multiple merge requests per day and you don’t have time to dive into understanding the whole change properly. Just make sure the author is aware that you are mostly reviewing code style and obvious violations and not the logic itself.

Make sure you adapt the style of your comments to the person who created a merge request. If it’s a senior developer or a developer who has been working in your company for a while, maybe the comments can be shorter and to the point since that person is more likely to understand them correctly. On the contrary, if the developer is new to the product or doesn’t have enough experience, it might be worth writing comprehensive comments explaining things in detail. Make sure your comments are friendly and not aggressive so that you can give the author some support and ensure that they don't feel attacked.

Beware of emotional damage. If you write too many comments on a review, it may overwhelm the author. Try to keep the most significant comments and move some of the comments offline if you decide you need to explain something in more detail. Our goal is to encourage a positive approach and harness productivity among colleagues.

In continuation of the previous idea, it’s worth mentioning that usually, it doesn’t make too much sense to argue in comments. If another developer disagrees with your feedback, the most productive way may be to move the conversation offline or a chat. Avoid making colleagues feel publicly attacked or judged, and never keep arguing just for the sake of arguing. Instead, try to combine your efforts to find a constructive solution.

To Sum It Up

As you can see, the purpose of code review is not only to find errors and problems but also to share knowledge and experience between developers. It helps to improve code quality and raise the professional level of the development team. 

Well-organized code review does not only mean optimized workflows, following processes meticulously, and effectively catching bugs and potential vulnerabilities in the code. It is also an area where developers’ soft skills are especially pronounced. It may be more difficult to conduct a good code review than to write good code.

I can easily tell that building a collaborative and consistent code review process among developers is vital for developing a high-quality product. It can not only save money on damage control and fixing issues at late stages of development but also encourage teamwork and knowledge sharing in your team.