Thursday, July 4, 2013

Code review : A necessary evil


Do we really need code review? Ideally speaking, we don't. But idealism is seldom practical. If people write their code properly without any bugs, there is no need for code review. But is this humanly possible? Naah!

I have talked to my friends who are working with different OEM companies about code review in their projects. Most of the responses fall under three categories:
  1. There is no code review as everybody is pretty good with the code. Also, a lot of regression testing takes care of the bugs.
  2. There is code review but not many people takes it seriously.
  3. There is code review and everybody takes it very seriously. For bigger code changes, multiple reviewers review the code.
I have been part of multiple projects where we maintained larges software for various clients and we have always been in the third category. So I think I am not qualified to outline the advantages of no code review but let us look at what does a strict code review brings to the table:
  1. A reviewer is a different person. He thinks about code differently. So he brings in a different perspective when looking at someone else's code. He can look at the modularity, scalability and maintainability of the code as a neutral person. Believe me this has really helped me (and our projects) a lot.
  2. Developers are usually in hurry. They need to finish the current task at hand and move to the next task. A code review helps in establishing that a feature has been implemented as stated in the requirements.
  3. Developers are usually bad unit tester. During unit testing, they tend to miss the negative test cases or specific scenario test cases. A reviewer during the code review can identify some of these negative and specific scenarios for the developer to test. This increase the overall reliability of the feature.
  4. If you identify the code reviewer smartly, you can use this exercise to train new people in code as well as code review.
All these reasoning looks pretty good but are there any side-effects? Yes, there are.
  1. I have witnessed first hand that a some review comments late in the review cycle can create havoc. Developer tries to carry out the change fast as he needs to commit his code and usually forget to handle some special cases which he had taken care in the first phase.
  2. A similar situation comes when code review process gets delayed for some reasons. In couple of weeks, developer may not remember why a code is written the way it is written. So when a comment is given in that part of the code, developer is not sure what to do and might end up breaking his own code/logic which was most probably correct.
  3. A developer will have to allocate 20% of total development time for review.
There seems to be both pros and cons of doing code review. So what is my take?

I think I will go with the title, 'Code Review is a necessary evil'.

To learn something more on this topic, I would request people who have followed 'No code review' policy to please mention the advantages and disadvantages they see with 'No code review' policy. May be then, we can debate on what makes more sense.

2 comments:

  1. Well I too believe in approach of code review. It brings fresh perspective to implementation, but there are some scenarios where a code review can become an ego clash between two people, so I think to an extent it is the responsibility of reviewer to comment appropriately.

    ReplyDelete
  2. It is really nice to see that you also believe in code review. I agree that sometime there can be disagreement on specific code. In our project we have usually solved such disagreements by involving a third person who provides his/her unbiased view. I agree with you that reviewers should comment appropriately and it usually automatically happens because this reviewer will also be a developer. Finally if its something to do with the style of code, I feel that developer should be given the freedom to write a specific logic in his style.

    ReplyDelete