Photo by Farzad Nazifi on Unsplash

There’s a lot of guides on the best practices for code reviews but in practice it’s very hard to stick to those ideals. In the real world, teams are under pressure to deliver which leads to a decline in quality without solid processes in place.

In this post, I will try to set out a simple guide on how to implement beneficial but practical code reviews into your team’s development process.


I will occasionally reference technologies such as git as well as concepts such as a story from agile development. This is written more from a point of view of code reviews in web development, but I’ve tried to make it applicable to all areas.

The what and why

If done right code reviews (CRs) are one of the best tools to ensure code quality and maintainability. The main benefits are:

Think you’re ready to push your code?

Finishing a story can be a great feeling and it can be tempting to jump onto the next task. Taking a few minutes here can save you a lot of extra work if your code keeps getting sent back from reviews with reasons you could have easily made sure were sorted.

A quick list of things to do before you open that PR (may vary depending on your language and stack):

Things like unit tests, code coverage, and limiting checks can easily be set up to run as a git pre-commit/push hook.

Doing the review

There are too many tools out there for reviewing code for me to suggest a set way to do them. What you use will depend on your process, source control tools, and development pipeline but they should all let you do the basics you need.

As with the steps for getting ready for a review, these will depend on what kind of project and story you’re working on. A lot of the steps are the same as mentioned above as the committer should have already sorted any issues related to those… for these, the reviewer should just be confirming they are done.

Initial steps

Some of these could easily be automated into feature branch builds/hooks to reduce the time a reviewer has to spend on trivial tasks.

Objective steps

This is the most important part of a CR where the reviewer can use their experience and domain knowledge to validate the changes. Things to consider when reviewing the change:


Make sure you are considerate when rejecting or commenting on a CR as it should not be viewed by the committer as a critique on them. A CR is a tool to improve the quality of the code being delivered and utilize a team effectively.

The use of reject should be used as little as possible in line with the team’s process. A PR should only be straight rejected if there is a major issue and should include a comment to explain why. Ideally, these should only happen if there is an issue that requires further investigation or a breakaway session to review with others. If the PR needs to be rejected due to unit tests or linting areas then the team’s process should be reviewed to add measures that prevent these from getting to a reviewer.


When adding comments, make use of the review tools to add the comments in line with the relevant code when possible. Make sure to keep the comments short and descriptive.

If something is not understood, try to have a chat with the person who committed it to avoid unnecessary back and forth.

Doing code reviews together

Having the person who did the changes sat with the reviewer can be very beneficial for all devs on larger or more complex stories.

Reviews like this can be especially useful for junior developers as it gives them a chance to get comfortable doing reviews while having a more senior team member to make sure nothing is missed.

Making time for doing reviews can be hard so it’s important to share the load between suitably experienced team members where possible. Don’t rely on a small set of developers to do all the reviews as this will get rid of any knowledge share benefits.

How code reviews fit into your process

To make code reviews effective you want to be doing them before the code goes into a shared branch so the review gets done on a feature branch. This ensures any issues in the change are caught before they affect other developers or end up in an environment.

How to add code reviews into a development pipeline is a little outside the scope of this post so the actual implementation is up to you.

Senior UI Architect @ihsmarkit. I talk about process, architecture and security.