Code reviews are a commonly used quality gate, and form of best practice, in Software Development. Code reviews can also be considered a form of software testing.

When they are designed and used properly, code reviews can bring huge benefits for the quality of software products: allowing for defects to be identified and fixed, documentation to be improved and code to be sanity-checked. When code reviews are designed incorrectly, code reviews can often become a burden and a bottleneck for developers and testers alike.

So how can you make sure that code reviews deliver maximum benefit for your teams, and for your product’s quality? I have three ideas.

Automate, automate, automate!

Make use of automation tools to steam-line the review process and reduce the workload for reviewers. Many of the more standard and repetitive elements of a code review an be automated:

• Check functionality using an automated test suite, and ensure this suite is passing before the review takes place. Test automation tools often produce reports which can be quickly analysed by a reviewer if needed.
• Verify formatting using linting software to help ensure code is written in a standardised and readable way.
• Identify potential run-time defects by using static analysis tools to analyse code before compile time.
• Ensure traceability in the code by automating creation of a link between a code review and requirements.

These checks can be integrated into a CI/CD pipeline and triggered to execute on events like code commits, or pull requests being created. Performing these checks automatically before the reviewer even sees the code can hugely reduce the time needed to perform a review, and also make code reviews less repetitive and administrative.

There are many DevOps and CI/CD softwares out there to support this, and examples to look at include Azure DevOps, GitLab, Jenkins and the Atlassian tool suite.

Define a process

Of course there are some aspects of code quality that cannot be checked automatically: checking documentation is complete and makes sense, looking at the architecture of the code etc. This is where reviews add the most value. To ensure maximum quality is produced from code reviews, it can be helpful to define a process, guideline, standard or a checklist that reviewers should use when reviewing. Having a standard set of checks in place can help to protect against anything being missed during a review.

These processes or guidelines should always have room for flexibility. Code reviews can hugely vary in scope, size and risk and so some checks may not be needed in every review. Some items that could be included in a code review checklist include:

• Documentation sanity checks: do the docs make sense? Are there any gaps?
• Is the code structured appropriately?
• Are there any bugs or potential security risks in the code?
• Do all the automated checks pass?
• Does the code follow your organisations’ best practice policy? (If this check can’t be automated)
• Is the size of the code being reviewed too large? This is particularly important! If a code review is too large or complex, the review time grows massively. Keep code reviews small and simple, and potentially use the single responsibility principle to define what should be considered as a code-review-sized item.

Use reviews as learning opportunities

Finally, don’t forget to use code reviews as an opportunity to share knowledge amongst your team. Teams can often fall into the habit of having the same people reviewing the same areas of the codebase. This can be bad for two reasons:

1. Having the same person review similar areas of code consistently can lead to complacency, increasing the risk of defects and other issues being missed during review.
2. It can strengthen information and knowledge siloes, and increase your key personnel risk. If only a small percentage of the team has knowledge about a piece of code, this can cause issues in continuity if those team members become unavailable.

To prevent these issues arising, reframe your code reviews as knowledge sharing exercises. Ensuring that code reviews are shared with other members of the team can help them learn about new areas of the code base. Having a fresh pair of eyes on a piece of code can also lead to assumptions being questioned, more defects being found, , and new ways of working being innovated. It can also be a good opportunity for peer mentorship and providing team members with an opportunity to develop their communication skills and improve their programming ability.