In this post, we’ll discuss how to review your code and why you should get into the habit of doing that.
But before we begin, I’d like to briefly point out what is a code review.
What is Code Review?
Code review — sometimes also known as peer code review — is a process that typically involves one or more software developers checking another developer’s code before it is implemented into the codebase.
There are many reasons why someone should get their code reviewed.
Some of the reasons are that developers can make sure that the code you want to merge into the codebase follows the best practices, they may find errors or any kind of problems that caught on at an early stage can save you some headaches later on down the road, and the list can go on.
But in this post, we’re going to be focused on different ways you can review your code and I’ll also give you some reasons why you should review it.
Let’s get started.
Meet all task requirements
Let’s picture the following scenario.
You worked on a task for a few days, you wrote the code, you tested it and everything seems ok.
You create a pull request, compare the differences between your branch and the one you’re going to merge into and everything seems ok here too.
But there is one important aspect during a code review that is often overlooked by both the developer who coded the feature and the code reviewers.
And that is: checking that the code meets all the requirements of the task.
Sometimes when you’ve been working for days or even weeks on a task, it’s normal to not remember all the business requirements, so this is the perfect moment to check them one last time.
So before you decide to get your code reviewed by peers, take another look at the requirements of the task and make sure you’ve covered them all.
If you have not met all the requirements, it means that the task you’re working on is not yet done and your code is not ready to be reviewed just yet.
Change your mindset
Let’s picture a different scenario.
You’ve done the job of writing the code and before you create a pull request, you want to review your code before anyone else.
Let’s say that you’ve found no grammatical errors, the indentation is done properly, the variables are correctly defined but there’s a good chunk of code that you have abstracted and you are not sure you’ve done the right thing.
At first glance, the abstract code seems to be just fine.
But because you are a responsible developer who wants to prepare the code review as well as possible, you’re looking for ways to review your code as objectively as you can.
So the question is:
How do you review your code as objectively as possible?
My answer is to review your code with a different mindset.
In a code review, we can identify two mindsets: the author and the reviewer mindset.
You’ve probably already guessed it. You have to change hats and adopt the reviewer mindset instead.
There are several ways you can change your mindset. Some are easier than others, but it depends from person to person.
In this context, I can only talk from my own experience on how I change my mindset when it comes to reviewing my code.
After I finish writing the code and I made sure I’ve met all the task requirements, I take a break to refresh my mind.
It’s important for me to take a break because it helps me stop having tunnel vision and also helps me change my mindset more easily.
When I get back to the code, I try to think about how people with different backgrounds, assumptions, knowledge, and experiences would review the code.
And then I start asking myself various questions, something like:
Can a junior developer understand the code?
Is my code too abstract?
How will this affect the project in the future?
If I try to figure out if I’ve covered all the use or edge cases, I try to put on my Quality Assurance hat and I start asking myself other different sets of questions:
If I do this or that, how will it affect the app’s performance?
Can I implement the code in another way to improve the UI/UX or any API communications, for example?
In essence, changing my mindset helped me identify issues that I would not otherwise have identified.
In addition, it’s a good exercise that you can also do in your personal life in different situations.
The ability to see things from different perspectives can make you a better developer.
Rubber Duck Reviewing
Alright, so we’ve talked about why it’s important to have different perspectives and how changing your mindset can help you improve your code.
Keeping up with that theme, I’d like to propose a new approach for a well-known debugging technique: rubber duck but for code reviewing.
Let’s call it Rubber Duck Reviewing.
If you don’t know what rubber duck debugging means, I have a video and an article about it in which I go into detail about its benefits.
I’ll also leave a link in the description down below, but I’ll explain it now in just a few words so that I don’t force you to context switch.
Rubber duck debugging is explaining your code, line-by-line, to a rubber duck.
And you may be wondering why would you talk to an inanimate object while you’re reviewing your code.
Similar to using this method for debugging purposes, you’re going through the same mental process when you’re explaining to the rubber duck the code differences from the pull request.
You’re teaching the rubber duck the ins and outs of your code and by doing that you are deepening your understanding of your code.
When you’re explaining the code line-by-line to the rubber duck, there is a change of perspective, and like I said earlier, having the ability to see things from different perspectives can help you identify issues you would not otherwise have identified.
Automated Code Review
Another solution you can adopt is to automate some parts of the code review such as fixing indentation, coding style, unused code, error-prone code, compatibility issues, code security, and so on.
There are plenty of tools that can do just that.
These tools can automatically fix bugs or guide you on how to fix them.
Automated reviews can save development time but they are not a replacement for manual code reviews.
However, they can make manual code reviews more efficient since they save human reviewers from looking for minor issues such as indentation, function naming, unused code, and so on.
Many companies have integrated automated code analysis tools and there are various solutions on the market.
From IDE plugins like Editorconfig to more complex and robust solutions like SonarQube.
There are plenty to choose from.
Code Review Stack Exchange
If you’re a developer – which you probably are since you’re here – you’ve likely used StackOverflow.
But did you know that there is a place similar to StackOverflow but for code reviews?
It’s called CodeReview.StackExchange.Com and if you’re looking for feedback on a specific working piece of code from your project, this site may be useful to you.
This community can help you with feedback on best practices, design patterns, security issues, performance, and sometimes even edge cases.
There are a couple of things that I think you should know before using the site.
The first thing to remember is that the community doesn’t know about your project or business and they will not be able to give you feedback in this regard.
Secondly, be mindful and understand the implications of posting significant chunks of your code anywhere on the internet.
You may encounter various legal issues, especially if you post pieces of code from the projects of the company you work for.
I recommend that you use the site only for your personal projects, especially if they are open source, to minimize the risk of someone stealing pieces of your code.
Wrapping up
In this post, we’ve covered several ways one can review their own code.
We’ve talked about why is important to take another look at the task requirements before you send the code to code review.
We’ve pointed out the benefits of different mindsets and I’ve also proposed the rubber duck reviewing approach.
We’ve also acknowledged the benefits of automated code reviews and their downsides.
And last but not least, we got acquainted with the codereview.stackexchange.com website.
I hope you found some value in my approaches and that you can implement at least one of them in future code review sessions.
Let me know what you think about this article in the comments section below.
If you find this article helpful, please share it with others and subscribe to the blog to support me, and receive a bi-monthly-ish e-mail notification on my latest articles.