What’s The Real Essence Of Code Review?

Editor’s Note: This is a repost of a Medium post by Olaide Ojewale, a Lagos-based Ruby on Rails developer who is currently working with an early-stage wearable health tech startup through Andela. Olaide is interested in Android and Machine Learning, and when he’s not coding, you can find him watching football or learning about business.

Recently, I was reviewing code for a feature on a project I’m working on. I was doing the review quite late — I should have done it a few days earlier but I was reluctant to.

Why? Because I trusted those who wrote the code. There’s probably no need to review the “good work” they must have done, I thought.

Even world-class code deserves world-class review.

Why? Because I still needed to review the code in order to be familiar with the codebase. But that’s not all: There’s more to code review than getting familiar with the codebase. So I took a look at some resources and decided to compile summary of what I found.

Here, I’ll be talking about what code review is, what code review is not, why code review and tips to encourage code reviews.

What is code review?

Simply put, it is a systematic examination of computer source code.

It is intended to find bugs overlooked in the initial development phase and improving the overall quality of source code — hence the software.

Some people believe that code should be reviewed by teammates alone, but I believe that it should be the writer as well — not only because you may figure out some faults on your own, but because it will make your teammates more willing to review your code knowing you’ve thoroughly examined it first.

There are some questions that you should be able to answer while reviewing any piece of code:

  • Are there any logical errors or obvious security vulnerability in the code?
  • Looking at the requirements, are all cases fully implemented?
  • Does the new code conform to existing style guidelines?
  • Are there sufficient automated tests for the new code?
  • Does the code follow SOLID principles?
  • Are there performance glitches in the new code? E.g making avoidable calls to the backend (or external services) or using the wrong data structures for certain operations.
I think that is the most useful thing that a community of programmers can do for each other — spend time on a regular basis reading each other’s code. –Douglas Crockford.

What code review is not:

Code review is not nitpicking. It is not an avenue to show that you know how else something could have been implemented when it will not improve the system.

It is not an opportunity to hit back at a teammate or colleague that found a glitch in your code earlier.

It is not damning. It shouldn’t condemn the efforts and thought processes of others.

Code review is not the habit of just putting that nice comment or a thumbs up on a PR without actually going through the code.

Why code review?

The essence of code review cannot be overemphasized. Here are some of the reasons — mostly beneficial — why we (should) practice code review:

  • To facilitate knowledge sharing across the code base and across the team.
  • To ensure maintainability of code — hence the project, especially when a team member has to leave the project.
  • To learn new technologies and techniques, as we’re never always on the same level of knowledge with all of our teammates.
  • To reduce code smells.

Tips to encourage code review:

  • Make your code usually less than 200 LOC (lines of code) and never more than 400. When code is too lengthy, reviewers tend to get overwhelmed and stop uncovering defects — or stop reviewing completely.
  • Be open to feedback in terms of review and be happy to discuss about it when necessary.
  • Only raise your code for review after all tests have passed and it has a successful build on CI.
  • If possible, notify your teammates when you have completed a new feature and it’s ready for review.
  • As a reviewer, always ensure that your review is healthy to the self-esteem of the writer of the code.

The act of reviewing code should only get better if we want to keep crafting better software. I hope this helps in that direction.

Keep up with Olaide on Twitter and Github.