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 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
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.
· 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.