Opinion: The Benefits Of Code Review

[In this reprinted #altdevblogaday-opinion piece, Blitz Game Studios' technical manager Lee Winder outlines why code reviews are important and how they can benefit your team for future projects.] I am a big fan of code reviews, but they have a bad reputation. Worries about wasting time or getting bogged down in pointless and irrelevant discussions can cause the process to be dropped before it's even started. So why am I such a fan? Sharing Experience And Knowledge It might surprise you but this is one of the main reasons why I love code reviews. People learn best when they are surrounded by people they can learn from, and allowing those people to cast an eye over the code you are writing and talking about how something can be improved are invaluable. Having people suggest different ways to structure, optimize, and write code might seem a little late when it's already written, but it's something people can take with them into their next task as they grow as developers. And it works both ways too. Less experienced programmers might have their work discussed and improved, but it also allows them to question and push code from more experienced programmers who might be a bit more stuck in their ways than they should be. Improving Code Quality This sort of follows on from the above point, but as people are learning from each other, they are becoming better programmers. They are learning to avoid common mistakes, and as a result are writing more stable and easier to read code. Programmers will also start to spend a little bit more time checking over the code they write. No one wants to put up a review only for someone to find a rookie mistake in the first five seconds, so small errors that in the past would have been checked in only to cause havoc later get found before the code is even committed. Finding Bugs It might just be me, but nearly every time I've asked someone to put up something for the first time, at least one bug is always found. It might be a misplaced define, a + instead of an –, or any number of things but there's always one. And the time it took to post and complete that review will be much less than the time it takes for that bug to be found, a bug report written, the author to read the bug, find the code in question, do some tests, and then finally fix it. But I generally find that the number of bugs found during code reviews starts to drop off over time. This isn't because people are getting lazy and not casting such a critical eye over the code but because the quality of the code is getting higher and higher. As a result, all those bugs that might have otherwise found their way into the code base aren't even being added, let alone fixed early. Sharing Domain Knowledge The more people know about a particular system, the better. Illness, team moves, and resignations will always be part of the working environment, and it means that the key team member you are relying on could end up not being available when they are needed the most. And if you need someone else to dive in there and fix a couple of issues that have been found by QA, how long do you think that will take? If a system has been constantly reviewed as it was developed, there will be a larger number of people who will feel comfortable getting stuck into that part of the code base. Coding Standards This is probably one of the main reasons people hate code reviews as they don't want every conversation to turn into a discussion about where the bracket should go or what pre-fix that variable should have on it. How much of a problem this is depends on how strict your coding standards are and how by the book your code needs to be. So it certainly has it's place in a code review. Developers new to the team can be given documentation about coding standards, but it is one of those things that tend to easily slip, and there is no reason why this shouldn't be picked up in a review. Of course you need to be careful that your reviews don't start to get swallowed up in standards talk and the important elements like code quality start to suffer. And There Will Be More These are not the only benefits of code reviews, but to me they are the stand outs that make code reviews a vital part of the development process. Let me know if you have any more! In the future, I'll look at some of the main reasons why code reviews can fail and why some teams will not get the benefits that they should be doing. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions. Image by Sebastian Bergmann. Used under license.]