Why you need code review for your team

Code review probably one of the simplest and effective way to improve quality of the software product and still a lot of companies and teams don’t do it.
How Google came up with all those high quality tools and products we use everyday? Sure, they try to hire the best engineers available but this is only part of story.
Another part is they do code review in development process. As Mark Chu-Carroll wrote in his blog:

At Google, no code, for any product, for any project, gets checked in until it gets a positive review.

And why not? There is numerous advantages to have code review process and I did not come with any disadvantages except if you are writing crappy code and don’t want anybody to see it.

  1. Social Interaction. If you’re programming and you know that your coworkers are going to look at your code, you program differently. You’ll write code that’s neater, better documented, and better organized — because you’ll know that people who’s opinions you care about will be looking at your code. Without review, you know somebody sometimes will look at your code, but there is no sence of urgency, and code will be left as it is indefinitely.
  2. Knowledge transfer. 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. If that person takes time off or – god forbid – leaves the company, no one knows anything about it. With code review, you have at least two people who are familiar with code – the author, and the reviewer. The reviewer doesn’t know as much about the code as the author – but they’re familiar with the design and the structure of it, which is incredibly valuable.
  3. Finding problem. It is helpful when somebody else look at your code and maybe give some tips or insights, or find a bug
  4. Increased productivity. Spending less time on figuring out what this code is all about, even your own code written 3 months ago, or code you pick up from coworker means faster delivery. It is hard to document code outside of code itself. Having easy to read, well commented code is a benefit translated to better productivity later.

With modern tools and discipline code review could be done by team members fast and efficient. You don’t need to drop everything you doing to do review, but withing couple of hours it should be done because coworker are waiting for you. Team success translated in better product and in your personal success. The better code team developed, the better satisfaction all programmers get and better product delivered for the customers. If Google does it, then there is a good reason of doing it.

Submit a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>