Why should you use the Code Review?

First of all, I’m going to try to define what the Code  Review is.
What is the Code Review?
Code Review is a phase in the software development process in which the authors of code, peer reviewers get together to review code. Finding and correcting errors at this stage is relatively inexpensive and tends to reduce the more expensive process of handling, locating, making a refactor and fixing bugs during later stages of development or after programs are delivered to users.
Also there are other definition or comments about Code Review, one of the most important was done by Karl Wiegers in his article Humanizing Peer Reviews:
“Peer review – an activity in which people other than the author of a software deliverable examine it for defects and improvement opportunities – is one of the most powerful software quality tools available. Peer review methods include inspections, walkthroughs, peer deskchecks, and other similar activities. After experiencing the benefits of peer reviews for nearly fifteen years, I would never work in a team that did not perform them.
Opinion and data…
From my point of view, Code Review is necessary within a development cycle, because you can take a lot advantages:
  • Reduce number of bugs of a development task, and make easier the QA of this task.
  • It’s an opportunity to make a refactor and add improvements, because perhaps you have thought a solution but this one is not the best solution and perhaps, the peer reviewer has a good idea to improve that development, in addition to increase the quality of the code. Besides you can learn a new way to do the different develops.
  • Sharing the information among whole the team. In this way, all the team members will be able to do any task related to the project.
Furthermore, the importance of the Code Review is not only supported by my opinion, otherwise the book Code Complete , which has been written by Steve McConnell, provides objective data based on big companies experiences:
  • The average effectiveness of design and code inspections are 55 and 60 percent.
  • In a software-maintenance organization, 55 percent of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time after reviews were introduced. Before reviews were introduced, under 20 percent were correct the first time.
  • In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.
  • The Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent.
  • IBM’s 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1 percent of the errors that would normally be expected.
  • A study of an organization at AT&T with more than 200 people reported a 14 percent increase in productivity and a 90 percent decrease in defects after the organization introduced reviews.
  • Jet Propulsion Laboratories estimates that it saves about $25,000 per inspection by finding and fixing defects at an early stage.
Conclusions of a big study…
Some time ago,  IBM conducted a largest study on code review. It encompassed 2500 code reviews, 50 programmers, and 3.2 million lines of code at Cisco Systems. For 10 months, the study tracked the Meeting Place product team, which had members in Bangalore, Budapest, and San José. They got the following best practices:
  • Review fewer than 200–400 lines of code at a time

  • Aim for an inspection rate of fewer than 300–500 LOC per hour

  • Take enough time for a proper, slow review, but not more than 60–90 minutes

  • Be sure that authors annotate source code before the review begins

  • Establish quantifiable goals for code review, and capture metrics so you can improve your processes

  • Use checklists, because they substantially improve results for both authors and reviewers

  • Verify that the defects are actually fixed

  • Foster a good code review culture in which finding defects is viewed positively

  • Beware of the Big Brother effect

  • Review at least part of the code, even if you can’t do all of it, to benefit from The Ego Effect

Eventually, there is another way to do a code review, from my point of view, this is the pair programming. While one of the programmers develops the task, the other one corrects, helps and thinks to get the best solution. It is share information and get best solutions that the main target of code review is.
Bookmark the permalink.

Leave a Reply

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