Improving code reviews. Part 1; reactive improvements

An age-old story, engineers complaining about reviewing code, having their code reviewed, how long it takes, how much time out of their day it takes. No matter what, it is a vital part of our jobs, and isn’t really going anywhere fast. With the introduction of better linting, better CI, and better tools, it’s getting easier than ever. Responding to this, I wanted to take the first steps into improving our process, with the ultimate goal of reaching opinion only code reviews whilst simultaneously reducing cognitive load for engineers.

The Idea

This idea hinges on a pretty radical idea (at least in programming circles!) — code review should be entirely opinionated. That’s right, ain’t got no time for your facts here!

How do we improve our code review

The first steps I took in making that grey area a little smaller was to do a review, of our code reviews. A code review, review. I made a list of all the things that we pick up in our reviews; This is an ongoing process and evolves over time as the code changes. If you’re doing this for the time, here are some tips to get you started:

  • Find recent pull/merge requests that have had a number of comments, go through them and make notes of the comments.

The Reactive way:

Someone raises a comment on a code review, the team generally agrees with the principle of the comment, a change is made to enforce that principle moving forward. Be that via a lint rule, a syntax guide change, a README change or something else, the more automated the better of course!

Actioning those changes

A number of the smaller things can be picked up by linting, and some of them can be resolved by utilising the tools we currently use such as TypeScript, Prettier, testing etc.

Some examples:

One time someone left some code from an ES6 component in the file when upgrading it to TypeScript, so we added a rule, specifically for typescript files, that disallows the use of import PropTypes from “prop-types" — very simple, and no longer would that code pass the CI.

Some miscellaneous challenges & solutions:

Spelling; in my current team we mostly use vscode, and cSpell to have an IDE spellcheck, there are others available for other IDE’s — you’d be surprised at how many times this has caught issues for us!

So far

These implementation has been “reactive” so far, rather than proactive, however, planning and foresight can improve that.

Moving forward with proactive changes

Naturally, the key to this is to be proactive, and spot areas with the potential for mistakes.

Front End Tech Lead, you can find me on github @thomasparsons

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store