Why do we need the Code Reviews?

Thu, 04/11/2019 - 15:03

There are many options for improving the quality of software. One of the most effective methods is checking code with other developers.

Developers understand that the time they spend on viewing a colleague’s code pays off when other team members check their own results. Nowadays, most companies (for example, Facebook, Netflix, Google, Amazon, Uber) support this, so this is another sign that something is working well here.

Code reviews are both social interaction and best technical practice. Often the team attracts its colleagues to improve the quality of their code and improve performance.

But why do we need to request the expert review?

  1. Of course, the most basic reason is to find errors. If you do not ask for it you will miss errors in your code such as:
    1. Random errors - typos or mixing variables.
    2. Structural errors - dead code, logic or algorithm errors, performance problems or architecture. Often, for external reviewers, they are much easier to find if you look at your work from their point of view.
  2. You learn and become better - committers are guided by the opinion of the viewer who views the change request: the committer seeks to make ends meet, consolidate the TODO and generally improve the commit.
  3. Your code is not as clear as you think it should be testable and readable for others.

Code reviews are very important not only for developers, but also for product managers, testing engineers, designers, and others. In many cases, developers will be the first to see the benefits. This will allow them to move faster and better.

 

What are the benefits for developers?

  1. A cleaner code, more readable and testable, respectively, your performance improves.
  2. Best practices from other developers.
  3. Reduced unit testing time and debugging.
  4. Less debugging during system integration and testing.
  5. Share information about components and overall system status with other team members.
  6. Less time is spent reworking and reinventing the wheel.

Examples

In the Code Complete book, there are some good data that came from case studies of review results:

  • Insurance company Aetna found 82 percent of program errors through checks and was able to reduce its development resources by 20 percent.
  • The IBM 500,000 Orbit Lines project used 11 levels of checks. It was delivered ahead of time and contained only about 1% of the errors that are usually expected.
  • A study of the organization in AT & T, in which more than 200 people took part, showed that productivity increased by 14%, and the number of defects increased by 90% after the organization submitted reviews.
  • In software maintenance organizations: 55 percent of single-line service changes were erroneous before code reviews were introduced.
  • After reviews were submitted only 2 percent of the changes were erroneous.
  • When all changes were reviewed the 95 percent were correct for the first time after submitting reviews.
  • Before the reviews were submitted less than 20 percent were correct the first time.
  • n 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 into production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 tested had an average of only 0.82 errors per 100. Reviews reduced errors by more than 80 percent.

 

Tips:

  • No time? This is not a reason to skip the check.
  • Time - quality - function. You have to configure functions only when time is constant.
  • Make sure the project has time to review.
  • Do not use survey results to evaluate developer productivity.
  • Do not give reviews that do not offer a solution. Always give a good example.

Comments

Back to Blog Listing