Code Review, commonly referred to as a Peer Review, is a careful, systematic examination of the source code to improve the overall quality of the codebase.

Most people might believe that the purpose of a Code Review is to find – and fix – any errors or mistakes that might have been missed during the initial development phase, but this is not entirely true. There are mixed reports about the efficacy of Peer Reviews when compared to automated testing. Some reports put the average detection rate of defects as low as 25% for Unit Testing, as low as 35% for Function Testing, as low as 45% for Integration Testing, and as high as 60% for Code Reviews. However, a study conducted by Microsoft found that the detection rate for possible defects utilizing Code Reviews was around 15%, however, this study did not indicate which possible defects would qualify as a blocking defect.

While there might be a question about the efficacy of Code Reviews, there can be no denying that a defect discovered early in the development process – during the design or initial development phase – can be corrected much faster, and with much less effort, than problems that are found once the app has been released in Production. This means that Code Reviews are an easy way to reduce operational costs while also helping to maintain the company’s image and reputation.

So, if Code Reviews cannot reliably find – and fix – defects in the codebase, why do we do them? To reap the tremendous cultural benefits, as both a Development Team and as a company.

Promoting Openness: Perhaps the single greatest benefit provided by Code Reviews is the promotion of openness. Everything that we do, both as individuals and as a team, should be open to scrutiny from others. In fact, we should welcome – even encourage – such scrutiny because it forces us to examine our own beliefs. If the solution that we have offered is truly the best option then the scrutiny, by way of examination, will prove it, and the entire team will buy into it. Nothing should be free from critique, and instead of being threatened by the scrutiny of another, use it as an opportunity to grow, if not in your skills, then in your confidence.

Knowledge Sharing: The sole purpose of a Code Review is knowledge sharing. Code Reviews are typically conducted by Senior Developers who have more experience, both practical and theoretical, and experience than the Developer whose code is being reviewed. The Reviewer could very well possess knowledge about programming techniques or the codebase that could, not only greatly improve the code being reviewed, but also greatly improve the individual skill of the Developer. Likewise, it is entirely likely that the Reviewer will gain knowledge from the code being reviewed or from the Developer who created it. Either way, Code Reviews allow for a positive interaction and the open communication will strengthen the bond between team members.

Propel Teamwork: Code Reviews can be incredibly subjective, which can make them more than a little challenging. Some coding practices really are just preferences, with one being no better than the other, and Code Reviews force two individuals to reconcile differing points of view. The resolution of divergent perspectives requires that both parties function rationally as part of an effective and egalitarian team. Code Reviews should never be seen as a source of conflict, however, minor disputes can arise – after all, humans are complicated – so we should be able to resolve those disputes as a team. Not as individuals.

Raise Team Standards: As a team, we should all take great pride in our work. It is, after all, what we do. To do so requires having very high standards, for ourselves and for each other. The simple act of acknowledging this fact will perpetuate a virtuous cycle: we will want to honor the high standard that we have set for its own sake. Code Reviews allow the individual the opportunity to put a well-crafted piece of code in front of their peer, to show what your are capable of as a Developer. It provides the opportunity to have your hard work and skill acknowledged, and it also provides the opportunity to show your professionalism by being wholly receptive to the most deflating critique.

The Focus of Each Review

The Reviewer should focus on the areas listed below, giving priority to issues with a high severity.

  1. Security Issues = HIGH
  2. Performance Issues = HIGH
  3. Memory/Resource Leaks = HIGH
  4. Functional Issues = HIGH
  5. Error Handling = HIGH
  6. Scalability Issues = HIGH
  7. Control Structures = MEDIUM
  8. Logical Issues = MEDIUM
  9. Reusability = MEDIUM
  10. Naming Conventions = LOW
  11. Coding Style = LOW

The Goal of Each Code Review

The main goals of each Code Review are listed below:

  1. To find – and fix – defects early in the development process.
  2. Knowledge sharing between team members to gain a better understanding of the codebase.
  3. Maintain a high level of consistency in both the design and implementation of code.
  4. Identify defects that are common across the team in an effort to reduce work.
  5. Build confidence of each team member and the stakeholders about the quality of the technical execution of the Development Team.
  6. Establish a uniformity of understanding that will allow the interchangeability of team members when required.
  7. Recognition of the individual effort, skill, and improvement of each team member.
  8. Working together to reconcile differing points of view will result in a more cohesive and closer team.

Make sure to read Part 2 of our code review