Code review is a great practice that can help you and your team improve your skills and build better software. Most of the teams understand the value code reviews brings to the table: improved code quality, shared knowledge and responsibility, increased bus factor, faster onboarding of the new team members, etc. Yet many find themselves struggling to adopt the practice, while essentially there are only three key aspects to keep in mind that help you successfully start with code reviews.

These are: team, process, and tool.

Team

First and foremost, you cannot adopt code reviews without having your team on board and expect it to bring results. If your team does not see the value of reviewing code or does not understand the reasoning behind it, they will not be motivated to go through with it. Some may ignore or even sabotage it. Most people don’t like changing their routine unless there’s a good reason for it, so it is crucial to make sure the whole team understands what goals you set with adopting code review, what changes it brings to the development process, who is expected to participate and so on.

Let your team voice their concerns and then address them, have an open dialogue, discuss the potential problems you want to focus on with reviews, maybe even create your own code review checklist depending on the project’s needs.

Process

When introduced, code review becomes part of your development process, so you’d want to think where it fits exactly. Should it be post-commit review, pre-commit, pull requests, or maybe feature branch review? Ask yourselves, do you plan to review every single commit, or only certain changes? That largely depends on the kind of project you are working on.

Consider who’s going to participate in the code review process and who’s going to review code. Is it everybody, or only senior developers? Do you want new team members and junior developers to review code to get on board and learn faster? Note that best practices suggest the average of 2 reviewers, so if you want to have inexperienced developers participate in code reviews, it may make sense to pair them up with someone who is familiar with the part of the project under review.

Don’t be afraid of iterations. Code review is in essence an iterative process, and each iteration means that the practice actually brings value — a problem was found and addressed — or a misunderstanding was resolved. 

Don’t postpone reviews, but don’t spend too much time on them either. If you follow general software development best practices and keep commits small, it shouldn’t take more than an hour to review a change, likely a lot less than that; and it shouldn’t be hard to find this time for a review within 24 hours. Do a code review after lunch, or as the last thing before you leave the office, or as the first thing you do next morning when you come to work.

Tool

Find the right code review tool for you and your team. Luckily, you’ve got plenty of choice: from reviewing pull requests on github to full-fledged on-premises solutions like Upsource from JetBrains. Choose the one that fits in your environment (e.g. supports your version control system, issue tracker, has code insight for your language of choice, etc.), and your process. The right tool can help you not only record all the technical discussions you have during code review, but make the whole process smooth and efficient. 

Keeping these 3 aspects in mind is not a 100% guarantee of efficient and trouble-free code review from the start, but ignoring them will surely cause havoc.