Just like death and taxes, code reviews are simply a part of life. We’ve all had them, and some of us have even given them. Why is it then, that many of us are so bad at it?
The purpose of a code review is simple: to ensure that the code being merged into the codebase is up to a certain standard. On paper it sounds easy, but it becomes a lot more complicated when you factor in the interpersonal dynamics at work.
The secret is that code reviews can be done well, and without a great deal of pain. In this post, I will outline some guidelines and tips for enabling a better code review process within your organisation.
#1: Leave your ego at the door
Code reviews are not an opportunity for the people you work with to criticise you through the medium of code. If a colleague points out an improvement to make to your code, it is almost never because they hate you.
On the other side of the table: code reviews are not a time for you to mercilessly rip into someone because they bruised your ego in a meeting or took the last doughnut. Code reviews are an opportunity to collectively make better software, and should be seen as nothing else.
Unfortunately, things such as pride and bias do exist no matter how much we like to pretend they don’t. One step that various open source communities have taken is to do blind code reviews, where any information about the author of the pull request is obscured. However, having to adopt these practices in a smaller team is probably indicative of a wider issue.
#2: Automate what you can
Code reviews can be a time consuming exercise, especially when we have our own work to be doing too. A lot of time can be wasted on flagging up typos, dead code- not to mention the political hand grenade that is naming conventions.
Also, by automating these checks you are delegating checking for simple bugs and stylistic errors to an automatic process, and you can’t argue with a machine. Most of these checks can be run before every commit too, so offending code never actually makes it into the repository in the first place.
#3: Good is better than perfect
Code can always be improved, but anything past good code is diminishing returns. As much as we all want to think that we write flawless code, there is almost always some improvement that can be made.
Sometimes you will encounter a piece of code that passes all of the tests and is by all accounts good code, but you think of something that would make it better. Unless your change would make the code objectively better i.e. more efficient or more readable, just leave it.
It’s easy to disappear down a rabbit hole, and at the end you’ve spent an extra 2 days refactoring the code but it adds no further value to the product, which at the end of the day is the most important thing.
#4: Document your standards
A common thing flagged up in a code review is when code is not following coding standards. An equally common occurence is when these standards are not documented anywhere. If they aren’t documented, how will people know? From personal experience, I know that a lack of documentation on this will result in moving goalposts depending on who the review is assigned to.
You shouldn’t just document your coding standards, but agree upon and review them at regular intervals as a team. These standards should be a living document available for everybody to view, and by doing so removes the room for disagreements. Similar to a point I made in tip #2, you can’t argue about coding standards with a document that you helped create.
A lot of factors that can make code reviews so difficult to do correctly stem from people, not technology. As software developers, we are often portrayed as poorly socialised and reclusive, but the secret of the game is that people build software, not machines.
As much as we’d like to use technology to solve our problems, and probably could to an extent, the simplest way for your team to have better code reviews is to remove the opportunity for human flaws to inject themselves into your process where possible.
Hope this helps!