Code Reviews should be the universal rule of serious Software Development

As Wikipedia suggests, Code Reviews are intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.

WHY?

  • To Share Knowledge - In a lot of development groups, each person has a core component that they’re responsible for, and each person is very focused on their own component. As long as their coworkers components don’t break their code, they don’t look at it. The effect of this is that for each component, only one person has any familiarity with the code. Code reviews helps other developers get familiar with the other components of the code which they would not have looked at otherwise.
  • To Ensure Quality - There are lot of cases where developers go and reinvent the wheel. Sometimes there are flaws in the design  which can lead to security or performance vulnerabilities. But reviews are not just about finding bugs and vulnerabilities. Code Reviews forces developers to write readable code, it also reduces code complexity making it easier to change the code in future.

Publish Standards

  • Code reviews can be incredibly useful but intimidating as well and therefore Code Review should never be done without published code standards. If you conduct code reviews and you have no published standards, then a review can feel like an interrogation. Developers can learn from their mistakes but only if they know what their issues are. And if developers are afraid of the review process, the positive results disappear.

HOW?

  • Over The Shoulder - The simplest way to do review is Over The Shoulder. This method is really useful when the code change is not very big (under 200 lines?) and usually lasts short amount of time (about 20 minutes?). Even if paired programming works for you, it never hurts to get another set of eyes on the code
  • Code Review Tools – There are lots of great tools like Atlassian Crusible, CodeCollaborator, Review Board, etc. which assist with reviews. The main benefit of using Code Review Tools is that it can be done whenever the reviewer has has comfortable time that doesn’t break their concentration.
  • Review by Team –  Get the programmers together every fortnight and look at what has been committed. Put the code on a projector, discuss the code and talk about the mistakes. The best part about this process is that everyone knows what is being committed and every programmer improves their coding skills.

I firmly believe that Code Reviews are an effective way of spotting potential problems early in your code and it also helps rookie programmers to improve their skills. But remember to use tools for the right job, Code Reviews are not meant to check for static code or code standards. There are already tools like CheckStyle, FindBugs, JTest, etc for those purposes.

I would be really happy to hear some feedback on how you do code reviews at your workplace? And how useful they are? Thanks.

 

Tagged , ,
  • Huy Hoang

    Manish, that’s a great post on why and how of code reviews. I am making some notes to convince our development manager to bring this practice into place and your post will help a lot.

    Thanks a lot.

    P.S. I really like the picture you have included too :P

    • Manish

      Thanks.

  • Basu

    We pretty much follow what you just said, we basically use github’s feature to review code. Reviews definitely expose you to a lot of good and bad code :-)

    But all in all its for the greater good of the team.

  • http://gravatar.com/morphy76 morphy76

    We’re using sonar to gather several metrics; some alerts on them are the published standard to follow (i.e. code coverage, critical violations…). Still using sonar I can identify complexities that I can suggest to simplify. So… tempus fugit and sonar let me focus on hotspots instead to look at the entire committed code

  • http://gravatar.com/bindingguru Urs Enzler

    We do so called commit reviews. Whenever a developer wants to check in changes to the source code, he shows them to a peer developer. The result is that we have a lot of small reviews, which leads to better feedback.

  • Joachim Arrasz

    The best Code Review is done while Pair Programming *imho*