Code reviews are something that not all of us like or do, but they can be very valuable.  I thought I would express some of my thoughts/opinions about the benefits and pit falls of performing code reviews.

Benefits of Code Reviews
Performing regular and consistent code can have a great impact on your project.  Some of the benefits can be:

• Keeps code clean, can help enforce coding standards
  One of the great benefits of a code review it to allow the code base as a whole to maintain standards.  Along with maintaining standards, knowing your code is going to be reviewed will undoubtedly encourage the coder to write better/cleaner code.  Maybe they means adding a few comments where they would not have otherwise.  Maybe it means they will rethink their logic in order to make it cleaner, more readable. 
  
  All of this makes the code base better for future maintenance/expendability.
  
  
• Forces/enables outside options on your implementation
  Another positive that come from code reviews is that it will allow other team members to possibly come up with alternative ways to solve your coding problem.  This can be useful because maybe there is a simpler way to solve the problem and you did not see it.  As we know, Simpler is Better..
  
  
• Helps spread knowledge on code
  By having other people look over your code as well as having the intent explained to them, you are spreading the knowledge of your code.  This knowledge may only be in terms of intent, but the more people who understand the code base as a whole, the better.  You could also achieve this result with paring, but that is not the topic of this post

Possible Pitfalls of Code Reviews
Unfortunately there are a few pitfalls to code reviews.  Although in my opinion these are small, and most definitely can be avoided, you do have to give them thought.  Some of these pitfalls are:

• Feelings get hurt
  The first rules to performing a code review is to Critique the Code, not the Coder.  NEVER, EVER, EVER attack the coder, only critique (not slam) the code.  If for some reason the developer of the code feels they are under attack they will go into defense mode and start defending their code from the wrong angle.  
  
  If this happens they will not hear ANY of the positives about the code, only the negative.  At this point all is lost, better off stopping the review and starting over later. 
  
  
• Nothing of value comes out of the review
  If during the code review change requests are made, make sure they are acted upon.  If these requests are never acted upon and the pattern of this starts, the code review process is simply a waste of time.  The developer will learn that they don't 'have' to make changes and they will not. 
  
  Make sure to perform the follow up later by just looking for the changes, or actually start off the next code review by revisiting the old code to ensure the changes were made.
  
  
• Too much time is spent on the review
  Code reviews should be short and sweet, 30 minutes tops.  If your review extends past 30 minutes, you are probably reviewing too much code. 
  
  By extending the review you will at some point start to lose focus.  When this happens the value of the code review starts to diminish.
  

Conducting Code Reviews
In order to perform quality code review there needs to Rules of the Game (hmm, sounds like the next post idea).  Without these rules, the review could get personal and this will not accomplish anything. 

• Performed on a regular basis
  Code reviews need to be conducted on a regular basis.  This can be weekly, once a month, once a quarter, what ever, just so that they are regular. 
  
  
• Keep the group small
  Keep the group performing the review small.  Maybe 2-3 'outside' people and the author(s) of the code being reviewed.  This will allow for the meeting to be shorter and more effective.  A large group will just cause process to drag on. 
  
  With keeping the group small, you can also create consistency with who is performing the review.  This consistency will lead to better results.
  
  
• Know what you are looking form
  Before you start the review, communicate the what is being looked for and what is be expected during the review.  This will allow everyone to be on the same page and allow for better results.  Besides, open communication can go a LONG way.
  
  
• Consistency
  Every code review should be as consistent as possible.  Make sure that the rules don't change from one review to the next.  Also make sure that what you are looking for does not change.  If in one review you are looking only at logic and disregarding coding standards, the developer will come to expect that next time.  When the next time comes around and you don't look at logic, only standards the developer will be confused and possible upset.

These are just some of my thoughts on Code Reviews, would love to hear yours...

Till next time