Conducting effective code reviews

Here at Codelitt, we have a basic rule: all new code must be peer-reviewed before being merged into production. If you’re still not doing this in your organization, I highly recommend you start to. It doesn’t take much planning, and the rules are simple. Initially, it’s enough to have anyone on the team review the code you wrote. Just from doing that, many (but not all) bugs will be caught, preventing something potentially dangerous down the deployment pipeline.

However, there is more than meets the eye when it comes to doing code reviews. In fact, there is interesting research that’s been done on this topic, suggesting that code reviews are indeed a valuable tool in software engineering 1 2. These provide some interesting metrics that you should consider if you want to have effective code reviews. Based on my experience, I feel that the following suggestions are very true:

  1. You only get effective code reviews when you do them at a pace of 300-500 lines of code (LOC) per hour. This varies a lot depending on the type of code being reviewed, the style of the original developer, and the person reviewing the code. But the point here is that there is a limit to what we can actually take in when reviewing code.

  2. Almost as a corollary of the previous statement, you shouldn't review much more than 200-400 lines of code at a time, and don't spend too much time in each batch, at least not more than 60-90 minutes.

It's important to highlight that you will have to account for additional time being spent in the development process to do code reviews. Code reviews should be considered as important as writing the code, and therefore should be considered when planning the ETA. As usual, having frequent, incremental commits helps with this.

  • Create checklist to be self reviewed before sending your code to be reviewed by others. It must list common pitfalls, and each developer should also develop their own list of mistakes and defects they know the make frequently. I would add that a standardization of the code helps as soon as there is homogeneity that helps with the review. For this, I recommend choosing coding standards (write your own or pick one that you like. For instance, for Javascript, you can use Airbnb's which is very popular).


Besides the previously discussed figures, the aforementioned studies also found some best practices when doing code reviews. Again based on my experience, the following are the ones that work the best:

  • Code review are an opportunity to assess the knowledge of coworkers, transfer knowledge, and share 'tricks of the trade'. For example, you might have developed a clever solution to a common problem, whereas a coworker is using an effective but inelegant solution. This is an opportunity to teach him and help improve his skills. It also helps to convey the standards and coding style that is used in the organization.

  • When adding comments, explain clearly what you mean, and try to provide code to support your ideas. This code doesn't need to be tested, it just serves to convey your idea.

  • If possible, pull the branch and execute it locally and actually test the code, even superficially. There's not a single time that I've done this that I haven't found something that wasn't working as expected. Then, instead of just reporting it directly to the person responsible for the change, do a little of extra work and try to find the place in the code where to leave a comment about this. It's not about finding the root cause of the problem, but to at least provide some useful context for the problem that you discovered.


Finally I'd like to highlight something that is usually bypassed: the human factor involved in code reviews. In my opinion, you should be always extremely polite, never be sarcastic and of course never undermine the work of a colleague, or otherwise the process of code reviewing will have undesired (some times devastating) side effects on the team as a whole.


Download our Incubator Resources

 

WANT MORE?

We’re known for sharing everything!

HANDBOOK

Save more time, get more done!

FREE HANDBOOK

Innovate from the inside

Written by
Luis Muñoz 13 Jun 2017

I'm an experienced software developer who has grown an equal passion for business and technology.

YOU MIGHT ALSO LIKE

comments powered by Disqus