Code reviews in a nutshell

When you’re working on a specific field, it is extremely important to never lose focus. What are the basics of your work? Why does it matter? Why do you do what you do?

We have decided to step back a little and take a good hard look at code reviews as a concept, and think through the basics of the work, why it matters, and how it’s become a cornerstone of software development.

What are code reviews?

Some concepts are so ingrained in our day-to-day activities that we have a hard time defining them precisely. A code review is one of them. A lot of confusion arises from this. One of the most common misconceptions about code reviews is that they are the same as pull requests.

This is false.

Not only are code reviews not pull requests, they can happen independently of them, and outside of version control systems, such as Git. These are all tools that make code reviews more effective and easier to perform, but they don’t define the practice.

Code reviews, or peer reviews, are any and all software quality assurance activities where a person (or persons) that is not the original creator of the code will verify it by reading it.

That’s it.

It’s that simple.

Why do we need code reviews?

There are a ton of automated processes for reviewing code, correct? And there’s a lot to be said about metrics that can guide a review, which can also be systematised even by someone without a deep knowledge of the code, correct?

So why do we need some of our brighter development minds to be spending a significant amount of time poring over code that has already been tested and passed?

For several reasons.

We need code to be readable. When we are performing code reviews, we aren’t just debugging, we are doing an exercise in creative reading. We are checking to see if we can perfectly understand everything the code does. Every codebase needs to be updated, and it’s just not practical to always rely on the original developer to do so. The code needs to be readable by someone else.

We need to transfer knowledge. A team that is composed of individuals that only understand the code they wrote is a team that doesn’t understand its own product. Code reviews aren’t just about improving the codebase, they are also about improving on what the team knows.

We need continuous improvement, not just fixing problems. A code review shouldn’t just focus on picking bugs or defects. The reviewer is a second set of eyes and a second mind, and they always need to be thinking critically. Are there better solutions? Can we improve quality? Can this be done more efficiently?

We need it for team building. Collective ownership is key. The team needs to know that every single line of code is owned collectively by everyone, not just by the person who typed. Code reviews make the team understand that everyone can contribute with valuable input at any stage of development in a practical sense.

So how do I do them?

We have a lot of thoughts about best practices regarding code reviews.

We understand not all of them are consensual, though, so here’s the bare minimum you need to do to implement an effective code review process with your team:

• Establish what to look for. Not all code reviews are born equal, and not all of them are looking for the same things. If you are making very minor changes to a function, for instance, you might not even need a review, even if it affects a significant number of files. Here are some things to look out for:
  • Purpose: Does the code do what it’s supposed to?
  • Requirements: Does the code do everything it should?
  • Design: Is the code readable and elegant? 
  • Functionality:  Does the code serve its users adequately?
  • Complexity: Could the code be simpler?
• Figure out how you are going to assign the reviews. Don’t just blast the whole team with a notification and have them randomly review things in their free time. Whether you’re assigning a senior and a junior developer or partnering developers in other ways, make sure reviews are assigned in a timely fashion to specific people.
• Make sure reviews are done in a humane way. One of the major roadblocks teams face regarding code reviews is that people sometimes tend to not handle the emotional aspect of going over someone else’s work in the kindest way. Reviews need to be about collaboration, not competition. We were lucky enough to have a guest post on our blog about precisely this.

If you are just getting started

We have made it our mission to improve code reviews, to make them more accessible and simpler for teams, and to truly make them an industry standard.

Reviewpad was designed to do exactly that, and you can try it for free.

You can do it right now, in fact.

Let us know what you think.