Quick Code Reviews

by Krishna on July 30, 2009

D’Arcy has a good take about how fast you can do code reviews. As he himself says, the example is a bit contrived, but the point remains: You don’t have to spend a lot of time to do code reviews. Many mistakes can be identified within a few seconds of looking at the code. If you are at the level where you have to spend several minutes analyzing the code to identify problems, then either the code is very good or you are a very bad programmer. Hopefully, the latter is not true, so at that point, you are at the stage where code reviews are reaching a point of diminishing returns.

Doing code reviews is perhaps the fastest method for improving quality in a team. It allows knowledge and experience from the senior members of the team to flow to the junior members, thus enabling them to improve their coding standards quickly. When a team starts doing code reviews, they can easily identify and get rid of the low-hanging fruit in code quality. This, in turn, provides greater stability to the product allowing the team to focus on higher-level tasks. A virtuous cycle follows where the team keeps building upon improvements in quality.

There are many reasons why people don’t do code reviews despite its advantages. One is that many organizations try to formalize code reviews, creating overhead in terms of planning, documentation and follow-up. What should be a few minutes gets planned into an hour-long session with templates to be filled and reports to be registered. Because it takes too long to do one code review, there are fewer code reviews done in total.

Another problem with formal code reviews is that it introduces hierarchy and power structures into the code review activity. Instead of one programmer providing constructive feedback to another programmer, we get metrics collection and performance evaluation. Programmers have to protect their reputation and ego and so try to avoid code reviews.

An important rule is that the more you do code reviews, the less people avoid them and vice versa. If you do a code review once a month, you will find more errors and this looks bad for the programmer. When you do frequent code reviews, you may find a couple of errors that the programmer can easily fix and it does not seem like an embarrassment. Also, the quality of code goes up with each code review (as people avoid older bugs) and they look forward to showing better quality code. The end state is that people ask for code reviews to show off their code and challenge you to find bugs.

Now, there are many tools that help you identify coding problems. My view is that it helps advanced programmers more than it does junior members. The latter need more direction and prioritization initially. Soon, they will know how to better use tools to improve their coding. Automated tools should be considered a complement to code reviews. Use them, but do not dispense with code reviews in a team setting.

An important thing to remember is that if you are doing a code review for the first time with somebody, only raise 1-2 issues so that they are more inclined to come back for more once they fix them. Comment only on the most critical problems in their code. Also keep the tone calm so that they don’t feel that they are in an inquisition. The whole idea is that they should feel that both you and them are working towards the same goal of quality in the product. It should never be about the programmer who has written the code.


Gregg Sporar July 31, 2009 at 5:42 pm

>It should never be about the programmer who has written the code.

Indeed. The idea behind code review is to review the code, *not* the coder. Further, another key way to keep things from bogging down is to focus on finding the problems and not on discussing in detail how to fix them. That’s a separate process. More code review tips available on our web site: http://smartbear.com/codecollab-white-paper.php

Kevin Rodrigues December 19, 2009 at 12:38 pm

Code reviews are a great way to improve the quality of the software. However as you have mentioned the formalization of the process along with the collection of metrics reduces it to just a thing that is done to show that everything is within bounds. In this the actual purpose of code reviews gets lost.

A place where I worked followed code reviews quite well. Anything which would be placed in the central repository would have to go through a code review before it could.

Comments on this entry are closed.

Previous post:

Next post: