There are some excellent articles like this, that talk about how to do code reviews. In this article, I talk about how to do code reviews without getting exhausted.
At a certain point in time, I was involved with several different projects and was doing lots of code reviews every day. So much so that sometimes an entire day, I just did code reviews. If you have experienced something similar you also may have noticed that it is quite challenging.
A reason behind this might be the absence of a reward.
Let me explain what I mean by reward. As a developer, you set out to achieve a functionality(goal) and once you reach your desired goal it is always verifiable i.e you can see the result/output or something in action. This instant feedback makes it enjoyable because there is a constant cycle of effort and reward.
When reviewing code this is mostly missing, you might spend time putting in the effort but you don’t get a reward always. The only thing close to a reward would be when you have put some feedback that improves the overall code quality or identifies a semantic error.
To provide good feedback you need to have some strategy to handle your code reviews.
Here are a few that I use:
1. Consider code reviews as a learning opportunity
This is tied to the idea of providing yourself with rewards. You can be sure of a reward if you consider all code reviews as a chance to learn more.
With code reviews you get to see how other developers might be thinking about a problem, giving you good insights and ideas for your next task.
The more code you see the better developer you become, you will push yourself to interpret the code in your head and with enough repetitions, you will be faster with that. This will show up in your day-to-day work as well you, will start thinking in code much better and clearer.
2. Start with an overview
This is important if you are reviewing a rather larger amount of code. Start with having a bird’s eye view of the code first. Check the associated ticket, scroll through the code, dip into some interesting parts and do a quick skim.
Once you do all this you will find yourself much more comfortable with what you are reviewing and going through code in more detail now would be much easier.
3. Tackle small chunks at a time.
Sometimes you will see 30-40 lines of code in a function and your brain will go on the back foot already.
You would start looking for shortcuts or would become distracted. Remember we want to learn and contribute to the project, if we are not focusing we lose both opportunities.
For me usually, I just pick 4-5 lines at a time. I keep code hidden outside the viewport and scroll in only the amount of code I can digest easily.
4. Optimize your code review setup.
Look for ways to improve your code review setup to be as efficient as possible.
I use my IDE for code reviews several times, it helps me with code hints and catching any obvious errors.
It also keeps it consistent for my eyes, as now I am looking at the code in the same environment in which I myself code, making it easier to understand the code.
5. Take breaks
When you are reviewing code, you have basically turned yourself into a computer, reading each line of code and executing it in your head. This entire process needs a lot of energy and you will eventually get tired if you are doing a lot of it.
Turn yourself away from the code if you feel you can’t focus much. Don’t worry that you won’t remember what you have already reviewed as your bird’s eye view and your notes(if you have put any) will help you get back on track. Also, even if it takes a few minutes more to come back to where you were it will be a much better outcome than doing a half-baked job.