Incorporating healthy code review approaches

This is part one of the two-part series on the importance of code review and the best practices of doing it. This part covers healthy code review practices. The second part will focus on the benefits of performing a code review.

Whenever a project starts, people with different mindsets and approaches work on it together. It is always good to have different ideas from different people. But the approach has to be positive or else it negatively affects the project. The same approach is required when doing a code review.

A brief look at code review

A code review can be as easy as a team member going through your code and recommending tweaks to improve the performance of the code, or as wide as running an automated tool followed by manual analysis to uncover bugs.

A code review takes time, so there must be set expectations of how much time a code review might take. So that everyone is confident and synced with each other.

It is important for the team to have a positive approach towards the project and its review. They must have a common goal of learning and sharing. There are many tools available for an automated code review. It is suggested to get the review done in both manual and automated ways.

Best practices of implementing code review

If a code is reviewed badly, it can bring a negative impact on the team performance and the code itself. Not all of us can be good at reviewing or commenting or even suggesting better practices especially if the approach is not positive. Hence we need to keep some of the practices in mind so that we are able to deliver better code as an author, reviewer, and as a team. Let’s read what they are.

Working as a team

Code reviews are a great source of knowledge and learning.

If an issue is caught early in the process, it helps everyone involved save a lot of time and effort. The more late a problem is identified, the more costly it becomes to correct it.

Reviews help all the team members to grow together and help each other learn and become a better version of what they are. Hence, discussions should be a part of code reviews.

Different ideas coming from different members will increase discussion and help in deciding which idea should be implemented. Code review is the best practice to learn and implement good coding styles. This makes code reviews a great source of knowledge and learning.

Working as the author

 Look at your code like a reviewer and go through every line of it.

While working as an author, you have to make sure you don’t leave any glitch that surprises the reviewers. There must be a PR description that explains the little details that are needed to be known by the reviewers. By doing this, you will be able to prevent the early queries or comments from the reviewers and they will gain a better understanding of what the project is about.

Never hesitate to ask for help from your reviewers. It would be best if you are able to work together before the review is done. 

Try to be your own reviewer first. Before getting into a team review, make sure you do a review first. Look at your code like a reviewer and go through every line of it. After you are done, hand you review over to the reviewers. But do not jump into their DMs asking them to review instantly. Trust them with their skills as they trust you with your coding skills.

Working as a reviewer

Try and understand the perspective of the author and then mention the changes.

When you start working as a reviewer, a common mistake made by a lot of people is that they start jumping to conclusions in the beginning. Try and understand the perspective of the author and then mention the changes. Ask questions, and don’t just assume things first hand. 

There are two kinds of questions that will help you avoid making assumptions. The first ones are the ‘how’ questions. When you do not understand what the code is supposed to do, or if there is a code that is hard to read or maybe a code that you are not aware of. 

The second ones are the ‘why’ questions. When you don’t understand why a code is used in a particular line, do not hesitate to comment or question. Explaining the context of code is important to understand the ‘why’ behind the approach of the author.  

Conclusion

Being the leader you always have to remember to not burden one single person, who has not worked on the code and has no idea what it is about, with the responsibility of reviewing the code. It comes with great benefits if done right. Now that we have learned that working in a team helps in a lot of ways, let’s not forget to implement all of these steps while reviewing or even creating a code.