How to Get the Most out of Code Reviews

April 17, 2020 · 3 min read
code review software engineering principles

Sleepy cat in front of MacBook Photo by Catherine Heath on Unsplash

Reviewing code takes time. Do you use this time to your best advantage?

Code reviews provide an outstanding opportunity to learn so many valuable skills:

  • give and receive feedback
  • find and fix bugs
  • write cleaner code
  • understand code faster

It also helps your team to share what's happening in your code base. But how do you get the most out of code reviews? This article gives you tips for authoring and reviewing pull requests.

As a Reviewer

When I review someone else's code, I follow four steps:

  • Do you know what the author wants to accomplish?
    If not, go read the ticket that is (hopefully) linked in the PR. This helps you to understand the PR better.
  • Do all linting rules and tests pass?
    When the linting rules and tests don't pass, the author is probably still working on the PR. You can go to see if another PR is ready to review. Or you message the author and ask how much they expect the code to change. If they're mostly finished, you're safe to go on with your review.
  • Skim the code. Do you think you could understand it?
    Before diving right into the details, briefly go over the code changes. See if 1) the code base is familiar to you, and if 2) you find any surprises in the code changes. This helps you to get an idea of the time the PR takes you, and the depth to which you need to understand the code.
  • Give respectful and constructive feedback.
    When you make a comment in your PR review, you are not writing instructions to a machine. You communicate with one of your team members. Be respectful and compassionate when giving code review feedback.

As an Author

When I'm the author of a PR, the following steps help me to make code reviews an efficient way to learn and improve code quality:

  • Open your pull request early as a draft.
    You can create pull requests, even when your code is not ready. (As long as it's marked as a draft!) That way, your reviewer can already read your code and give feedback.
  • Comment on your own code and ask questions.
    When you wrote some code you are not sure about, your pull request is a great place to ask questions. If you open your PR early, you can draft a solution and ask your peers for comments. Code comments in PR are not only useful for the reviewer. Ask questions. Ask if you’re on the right path. Tag people who could help.
  • Remember: it is about your code, not you
    When you feel embarrassed or offended by something your reviewer posted, remember that they are criticizing your code, not you. Online communication is hard and you should always assume miscommunication over malice.

General Tips

It helps enormously with code reviews when your project uses a linter with consistent rules for your whole team. This way you can avoid discussions about most small code style issues.

Save your reviewer's time by setting up automated linting and testing in a continuous integration (CI) pipeline. Most code platforms offer an integrated CI. If yours doesn't offer one, you can integrate any of the alternatives, like GitLab CI, Travis CI, or CircleCI. Just look for an automated way to run tests for open pull requests and to link the results within your PR.

Use code reviews as an opportunity to learn from each other.

Learn how your application works, learn how to improve your own code, and learn how to give compassionate feedback.

Back to Blog