All about effectiveness
Based on research we've conducted across hundreds of development teams, we've found that teams with a clear, and effective code review process greatly improve their code quality, so there are fewer bugs to fix. It also means they can ship code faster. In fact, across everyone we surveyed, code reviews were agreed to have had the single biggest impact on code quality.
However, if the code review process is poorly defined, it can be a source of enormous frustration and can even have a negative impact on team performance, with bottlenecks causing deployment delays.
Based on our research with hundreds of teams just like yours, there are some simple code review best practices you can follow
Define your process
One of the biggest mistakes is not establishing, and documenting a code review process. Without it, your team members won’t understand where, when, or why, they should review code.
Establish a process that works best for the size of your team, their needs, and level of communication they expect. Establish owners of the code review process, and define who will benefit most from the code reviews. Make sure that your process supports your key requirements, including knowledge sharing between more senior developers and engineers, and your more junior team members.
Your process shouldn't be static, it's always helpful to review best practices every six months and modify based on what's working, and what's not!
Define your code standards
Ask any group of developers how they define code quality, and you’ll get different answers from all of them. This can cause confusion, frustration, and propagate bad habits across team members.
Define your code quality standards as a team, document them, and stick to them. Think about code style, API conventions, naming conventions, and readability. It’s one of the most important things you can do to manage technical debt and reduce the amount of time teams spend refactoring code. To avoid arguments, and personal opinion, use an automated code review tool like Codacy, where you can define your code standards and manage them centrally.
Review code, not people.
It’s not unusual for a developer to spend 0.5- 1 day a week reviewing code, so it’s important that they understand why certain decisions have been made, and why the code review process is so important to your project (and their own personal development). Unfortunately, some developers feel threatened having their code reviewed by their peers, so set a tone of transparency across your development teams, and explain that the code review process should be welcomed, and is key to greater knowledge sharing and development. The process is there to review code, not them!
Keep a schedule and review early
Creating a schedule is a good way of keeping developers organised, engaged and committed. Code review should also be everyone’s responsibility, so share the load across your entire team.
Many organisations run their code reviews at the end of the development process. However, we’ve found that the teams that run code reviews before deployment, actually spend the least amount of time fixing bugs and making code changes. That's because, by running code reviews earlier in the process, teams are able to improve productivity by identifying issues before programmers waste time building more code on top of already broken code.
So, by reviewing early, and reviewing often, you can reduce code changes and simplify developer peer reviews.
Use code review checklists
So, you’ve defined your process and set your code quality standards. But that’s useless unless your team can work to an agreed checklist. Even the most experienced developers can fall foul to common mistakes when reviewing the code base. The best way to reduce the probability of errors is to use a checklist that takes into consideration the standards and quality that have been established for your product. Trust us, teams that have a quality standards checklist actually see fewer bugs and have more time to build new features. It’s also a great way to keep control of what's been done, and what still needs to be reviewed.
If you’re doing code reviews properly, the reviewer should have the power to block a pull request from being merged. The benefit in terms of code quality are obvious, but you might be nervous about the impact on your speed of delivery. Don’t be. From the thousands of development teams we speak to, 72% of code reviews are blocking. What’s more, they also have a code quality score that’s 10% higher than the rest! Of course, on the flip-side, reviewers shouldn’t unnecessarily block a pull request because of a subjective “opinion”! Respect the context (and knowledge) that the submitter has and evaluate issues against the agreed checklist.
The ultimate guide to code reviews - Edition II
Setting up a proper code review workflow might seem like a complex task at first, but by addressing this process early on, you guarantee better results in the long-term. For a more detailed guide, with recommendation drawn from interviews with almost 700 developers, download our ebook.Get this ebook