3 minutes read

Code review is the process of reviewing someone else’s code. It is usually done between project members that are working in the same repository.

Like software, the complexity of the code reviews has also increased, and it is easy to create conflicts, or have a bottleneck around reviewing code for your peers.

Usually, when a team of developers is working on a repository, they create their own branches where they write code for various features. When they want to integrate their changes into the mainline, i.e. the main branch, they need to create a pull request (or merge request), for their local branch. This is usually the main subject of code reviews.

Why is this important?

Each team should agree on a common framework for approaching code reviews. Code reviews are part of our daily jobs, and since we have different opinions and approaches, it would be optimal for everyone to have some high-level directions of what to look for and how to review code. This process would also help teams understand each other’s code style, and appreciate the variances between each style. This is beneficial when one has to refactor/fix a code snippet that is written by someone else. 

What should we look for in a code review?

• Code style – each team should adhere to the code style standards of their respective language. For Java, you can check this comprehensive style guide that has been published by Google.
• Readability and proper naming
• Overall architecture – this includes design patterns and general efficiency of the code.
• Complexity – could we make the code simpler.
• Comments – are the comments easily understandable?
• Tests – is the code covered in a good proportion by unit tests?
• Documentation – was the documentation of the code updated? E.g. changes in README file. 

Checklist for a code review session

1. Make your thoughts visible: express your opinion clearly about why something is wrong or why something should be changed. This will help the code author of not repeating the mistake in the future PR’s. Also, it might happen that the reviewer is wrong, therefore it’s important to reveal your thought process.
2. Provide an example: don’t just criticize a code that is not-so-well written. Try to come up with a concrete example of how it should look like. 
3. Speed is important: according to this article, many frustrations arise when the code review process takes too long, especially when the reviewer doesn’t implement the changes in a timely manner. As context switching can affect productivity, it is preferred an ad-hoc call to understand and explain over putting many comments.
4. Use conventional comments: conventional comments can improve the overall quality of the review comments. It can also mark optional changes accordingly, so it becomes the author’s decision to either implement them or not. 
5. Point the author to the exact issue: by targetting the right place in code, and also specifying what the problem is. You can reference to the section above to indentify the problem category. 
6. Use static analysis: by using this powerful feature that almost any modern IDE has embedded, you as an author can avoid pushing for obvious code errors.

Conclusions

Code reviews are super important for writing quality code. One needs to have in mind the various tools and frameworks in order to be a good reviewer. Having those in mind is essential for a performant team, the main advantage being that everyone will enjoy code reviews, and the constructive feedback will be easier to digest.
Let me know in the comments your thoughts on this topic.