A code review is where a developer has another developer review the code that they wrote. This second developer is generally someone who is associated with the project but not a primary author of the code being reviewed (avoids bias). This is a fairly common practice in development, but like any policy or procedure if you don’t know the purpose then it just becomes dead weight like a ritual that has lost all meaning.

So what is the purpose of a code review?

Purposes

Quality

One purpose is to ensure the quality of the code. The lesser part is that it acts as a double-check that the code meets the acceptance criteria for the user story or bug. Errors in that space should rarely get past the author’s own testing. The larger part is that the reviewer is ensuring conformity with agreed-upon standards and general best practices to ensure the maintainability, performance, security, stability, usability, and other aspects of high-quality code. This should raise the overall quality of the team’s output even if it has many junior members.

Learning

Another purpose is to help both developers grow. The reviewer should be bringing up alternate or better ways to author the code. They should be questioning why things were done the way they were if they would have done them differently. The goal is not to be nitpicky but to facilitate a discussion where both developers can learn from each other.

Each developer has their own experiences and perspectives. It is harder to share these in a meaningful way when just talking theory. Code reviews provide a practical context for sharing where all parties are invested.

Familiarity

An additional purpose is so that multiple developers are intimately familiar with the code. By the end of the review, the reviewer should be just as familiar with the code as the author. This ensures that both developers can support it and intelligibly discuss it. It is the team’s code, not the author’s. User stories and bugs for the same features shouldn’t have to go to the same developer every time. That would be inflexible and inevitably create bottlenecks.

Conclusion

The practice of the code review is important for taking full advantage of having a team write software. Too often a “team” is just a collection of silos which inhibit growth and flexibility.

Now ideally, a code review is not an event. Rather it is an iterative practice that occurs during development that culminates in a PR (Pull Request) that contains few surprises. It also takes time to do proper code reviews. How much time it takes depends on a lot of factors, but I don’t think it is odd to spend 1 hour in review for every 5 hours of development. So don’t just let it be a check-in-the-box. Invest the time in your team and your product.