My Approach to Code Reviews
A co-worker asked me how to deal with a particular code review the other day and I told them about the basics of my strategy. It got me thinking that it would be worth expanding on the idea, both for my future self and for others. The following three pillars of my strategy help keep my reviews from being controlled by my emotions.
Be open to learning new things
As developers, many of us think that we are always open to new ideas. Unfortunately, we are still human and much of the science tells us that we are more likely to clutch to an idea like a raft. For some people, this can be surprisingly challenging because they can see exactly how they would write the code and it can be hard to break from that. For other people, it will come naturally but the challenge lies in missing things because they expect the author to have a clearer idea.
Asking questions in a code review is a bit of a trick to make the reviewer more curious. Even when I think I know the answer or correct way to do something, I still ask the author. It gives the author the opportunity to rethink a decision and to possibly teach me something new. A concrete example of a question I have asked before:
You are using object destructing in your function parameter but there is only one value being pulled out. Why do you prefer to do this over having only a single argument to your function?
Clearly state assumptions
In my experience, I find that I am often reviewing code where I may not have the whole context of the application. On one hand, this helps to focus the review on what is made visible but it also means that many assumptions need to be made. By clearly stating those assumptions, the author is able to better understand the direction the comment or question comes from.
Code reviews are a great time for reviewers and authors to teach and learn new things. As a reviewer, approaching with an open mind and asking questions can lead to better results for everyone.