What I Learned From Failing My First Code Review

Practical advice based on my experience as a Front End Developer

I will be honest, I didn’t totally fail my first code review to the point it got declined but it did get totally picked apart by the lead developer on my team. This experience made me a better developer almost instantly in my first week of my new role by getting rid of the bad habits I had picked up from working in less formal coding environments and got me thinking about developing to a set of coding guidelines. It was also done in a way that allowed this self-improvement to take place without me thinking I was a terrible developer who would never reach the standard of the rest of the team.

My development background — Why should you take my advice?

I’m a Front End Developer, mainly concentrating on JavaScript for the past 5 years but with 10 years total experience. Before I became a JS developer I worked mainly with HTML and CSS with a bit of PHP thrown in there for good measure. I have worked in a wide range of development environments; from being the only developer for an online store, to working in small development teams at digital agencies to then moving into a more formal Agile development environment.

I have seen code review methods which have worked effectively and also those that didn’t work at all. The bad ones were mainly informal reviews which were supposed to be done at the end of the day before commits were made to our code repository but these rarely, if ever happened because it was too easy to forget about them. The good news is that I have also seen code review processes that have been very successful and I will share some of my experiences below in the hope they can be useful to other people.

Follow solid coding guidelines that the whole team agrees with

It’s important to have a set of coding guidelines in place that your team can follow. Many teams use an existing set of guidelines but modify and them to suit their specific needs. My current team started out using the JavaScript ES5 coding guidelines from AirBNB, however we have now started also using the JavaScript ES6 guide now that we have made the move to ES6.

My initial attempts at reviewing code

Here is the actual code review checklist that I came up with to help me initially when I started doing code reviews. I don’t need to look at it anymore because I am more experienced with code reviews and I have memorised what to look out for to the point where it is simply second-nature now.

JavaScript (Using ReactJS wih ES5 at the time)

· Make sure that all vars are being used

· Var declarations should be one per line

· Make sure all require() functions are being used

· Check that there are no unnecessary ‘,’

· Remove all console logs

· Remove all unnecessary commented out code

· Remove any hard coded vars which can be replaced by config var values

· onChange should go above render methods

CSS (Using SCSS)

· Make sure there is a line break between selectors

· Use $font-family… from _settings.scss

· Make sure there are no empty selectors

· Make sure you are using modifiers and selectors correctly when naming classes

These may seem like pretty basic things but it was a good checklist to use for my first few code reviews to get used to checking for the things which would eventually become obvious straight away.

Use effective code review tools

Use code review tools that allow you to create pull requests where you can add comments to specific lines of code, view changes to files and also see file diffs. The great thing about these tools are that you can get approval for your pull request before merging your code. If you’re using GIT, which most people are these days, tools like GitHub or BitBucket can do these things and are currently the most popular services.

Don’t expect to be an expert reviewer to begin with

When you first start out reviewing code make sure there is a more experienced developer on the code review with you to be able to guide you through the process and to also be able to pick up some more complex issues with the code. You should also make sure to there are at least 2 reviewers on each pull request where possible.

It may take some time before you’re offering suggestions which are more than simply finding code issues where someone has left an unnecessary comment in place or forgotten to remove some debugging output code. When you gain more experience you will start to suggest ways the developer could refactor the code to make it work more efficiently.

Think about the bigger picture

Think beyond the scope of your current development task. If you are working in an Agile environment you may be getting smaller stories to work on which means you end up building similar website components multiple times. Don’t fall into the trap of being lazy and copy and pasting whole sections of code and think that solution is good enough. If you are going to use the code more than once then you should turn it into a reusable function or component. This is particularly the case with component based frameworks such as ReactJS which I have been using lately.

Set aside time to concentrate on the review

Doing code reviews can feel like too much of an interruption to your normal workflow if you try to randomly fit it in between your own development tasks. Setting aside time at the start or the end of the day can be useful for concentrating on a code review. If you get an urgent review that can’t wait until these times it’s a good idea to clear your head before starting the review. A quick walk to get away from your computer for a few minutes usually does the trick.

Be respectful when providing feedback

Take the review “offline” and have a chat in person if you feel you’re making comments in a pull request which may be taken out of context or be offensive to the person whose code you are reviewing. You shouldn’t be making offensive comments anyway but some developers may be more sensitive than others and you should keep this in mind. Telling someone their code is stupid (I have actually seen this happen — Do NOT do this!) is not a productive use of a code review. You should avoid harsh criticism which is just for the sake of it and instead provide actionable feedback that the person having their code reviewed can either take on board and fix their code issues straight away or use it as a starting point of a discussion about why they don’t agree with your feedback.

Being positive never hurt anyone

If you do a code review and you think someone’s code looks really good make sure to tell them they have done a great job! It can do wonders for their confidence.

Embrace the code review process

The main goal of a code review is to make sure the code that makes it into production is high quality, bug free and actually does what it’s supposed to so that the end users of your product have a great user experience. Make sure to keep in mind that you are all working as a team to achieve the same goals and that code reviews, while an important part of the overall process, shouldn’t be something you need to be afraid of.

If you found this useful please recommend this article below. If you want to stay updated with my latest content you should add me on Twitter.

What experiences have you had with the code review process? I would love to hear them in the comments below.