It’s easy to imagine that code review is just about monitoring the quality of the code. Squashing bugs, checking best practices have been followed, sniffing out code smells etc.

It is good for that. Having someone other than the original author cast an eye over the development is useful – it’s very difficult to objectively check code that you have written and think already works (after all, you wouldn’t request a review if you didn’t think it worked).

But, it’s hard to get excited about code review if everyone on the team thinks finding problems is the sole focus. Who is going to cheerfully submit their work for their colleagues to tell them what mistakes they’ve made? Who wants to hand in their homework for collective marking?

Make it clear that the review process is not about criticising individual’s work. Instead, set the right tone and code review stops feeling like an imposition and obstacle to work but an essential part of your development cycle.

1. Ownership

This is probably the biggest benefit – and it doesn’t even directly relate to the code.

The code doesn’t belong to any one developer. If a developer wants to only work on their own code and have no one else work on their code they probably shouldn’t be part of a dev team and definitely shouldn’t ask anyone to review it. That attitude will torpedo to process before it has even left port.

Code review helps involve other devs in the work. This code belongs to the team and we are collectively responsible for its quality. Any of us might need to maintain it or add features in the future.

We’re not critiquing the one developer’s skills, we’re improving the quality of our code.

2. Mentoring

Asking a junior to get involved in code review is a great way to teach them. Not only you get them involved with the work of the team (see #1) but you give them the requirements and the code changes that were made to meet those requirements, on a real project with code that will go into production.

3. Learning

I used to spend the majority of my time developing. Now I spend the majority of my time planning, testing and reviewing development. With so many different technologies to work with and the rate of change how can you hope to keep up unless you are working with it yourself?

Code review is a big help. I’ve learned a lot about standard functionality (NAV and .Net) and seen problems solved in a way I wouldn’t have thought of – a better way.

4. Taking Pride

The simple fact of knowing that someone else is going to take a look at your work makes you take more pride it it. You’ll far less likely to implement some half-baked, hard-coded solution if you know that your colleagues are going to ask you why this code cuts so many corners.

5. Slow Down

An objection levelled against code review is that it slows work down. You need your work to be reviewed before you merge it into live. Your colleagues need to find time to do the review. We’re already busy, we don’t have time for this.

Code review does slow you down – in a good way. Ever been on site or support and made a knee-jerk code change to fix a problem? Ever had that change come back to bite you? And could you have foreseen the problem given more time to think about the consequences of the change?

I answered yes, yes and yes.

Of course some work is urgent. Of course you have the odd bug that must be fixed as soon as possible but do yourself a favour and take the time to think through the code properly before slapping it into live.

Conclusion

Adding a review stage into the development cycle is the single change with the biggest impact on code quality that we’ve made. I can’t imagine how we’d work without it now.

I’ve deliberately kept this post system-agnostic. I think the benefits apply regardless of the system you use to implement code review. In a future post I’ll write about our experiences with code reviews in TFVC and why we migrated to pull requests in Git.