What is a code review?
According to Wikipedia, “code review is a systematic examination (sometimes referred to as peer review) of computer source code”. In simple words - every new piece of code, before it goes to testing and then to staging and then to production should be examined by another team member. We can go to next stage, usually testing, only when the reviewer approved given piece of work.
Why to bother?
On the first glance, it seems like total waste of time - we’re wasting another developer’s time to read and comment code of his colleague and we still have to go through the normal process, like testing etc, so no visible advantages there. It will be easier to accept and understand when the code of only junior developers would be reviewed, but it’s not true - even the work of the most senior developers on the team should be examined.
But trust me, there are deep and profound benefits of this technique, on many levels. I’ll try to list just a couple of them:
Although code reviews have a lot of benefits, they have can introduce some issues. None of them is ingrained in code reviews per se, but be aware of their existence and take an action whenever you spot any of them.
First and most common is the fact, that programmer’s ego could be very delicate. People get attached to their code and sometimes they don’t take feedback well. Sometimes they treat it as an attack or undermining their abilities as a software developer. Another reason why the tension between programmers can occur is the inability of the reviewer to give constructive feedback - people sometimes forget that code review is a cooperation tool to improve code quality, decrease an amount of bugs and broaden understanding of the system - not to find the sloppiest developer within the team. To prevent this mindset from spreading across your company take care of positive attitude around code review. Make sure that everyone understands the goal of code review and teach your colleagues how to give valuable feedback without getting personal or offending anyone.
The second common problem that happens quite often is time pressure. When the deadline of an important feature is coming or your boss is not happy with a number of features your team had delivered last sprint/month/year, code reviews could be the easy pick to “streamline” the process. Unfortunately, there is no easy answer to this problem. The only thing you can do is collect metrics - measure amount of bugs that goes to production and compare it to the same metric when you do not do code reviews - the difference should be staggering and it will be a hard proof for the management that peer code reviews actually save them some money.
How to do it?
Now you know the benefits and potential problems of code reviews, so the next question is - how to do them to be as effective as possible and to deliver the maximum value from the process to the team?
I’ll share with you my approach to code reviews. I have to note that I build mostly web applications and this process works fine in this realm. I’m pretty sure that those are general advices and should work just fine in any software industry. Obviously, it may need some tweaks for you, but this is exactly what you should be doing anyway - iterate over the process, find out what worked for you, what did not and improve where you can.
Before starting a code review I want to read and understand the requirements - I want to read them before looking at the code not to get biased by the actual implementation. Next, I usually start with the general overview of the code. I want to make sure that I understand what the code is doing and I look for obvious mistakes - typos, bad variable or function names, commented code left undeleted etc. Nothing too complex, just to get acquainted with this piece of code and to find glaring errors.
After that I do one of the 2 things - I ask the author to walk me through the code or I start the more in-depth review straightaway. I want a face-to-face explanation when I don’t fully understand the code - for example when this is a new project for me or when the domain of the code I review is particularly difficult.
Next, I start doing the thorough review. This is the longest part of code review. When I do this I focus on things like this:
This is a general overview of my process and how I approach code reviews. It works for me, your process might be completely different - might be shorter, might include more people, or maybe face-to-face conversation are not feasible. Anyway - I think this could be a good starting point and from here you can figure out what will work for you.
The whole team should come up with the most effective way of doing the code reviews by themselves, but there are some general best practices that you can incorporate.
- Review for at most 1 hour at a time
- Take your time
- Look for omissions as well
- Limit LOC in code review
- Allow tools to do their work
- Use checklists
- Reinforce good practices
One of the biggest and best effects of regular code reviews is something called “the Ego effect”. Everyone starts to pay more attention to the code they submit since no one wants to be known as the guy who always makes silly, junior-level mistakes. It will skyrocket your skills and will boost your understanding of the system much faster and deeper than if you didn’t do it. Thanks for your attention! Stay tuned!Written on March 21, 2017