2021-12-04
Code review is something that I have been doing regularly at work. Every time a developer finishes working on a feature or a bug fix, before merging it to the main branch, another developer will review the code. At first I thought it was just about checking if the code works, but it is actually more than that.
The main purpose is to catch issues early. It is much cheaper to fix a problem before it reaches the testing phase or production. Another benefit is knowledge sharing. When we review someone else's code, we learn how they approach a problem, and sometimes we pick up new techniques or patterns. It also works the other way, when someone reviews our code, they might suggest a better approach that we did not think of.
Code review also helps keep the codebase consistent. When multiple developers are working on the same project, everyone has their own coding style and habits. Through reviews, we can make sure everyone follows the same conventions and standards.
When I review code, there are a few things that I usually check:
Does it do what it is supposed to do? This sounds obvious, but sometimes the code might miss an edge case or handle a scenario differently from what the requirements say.
Is the code readable? Can I understand what the code does without spending too much time? If I have to read a function multiple times to understand it, it probably needs to be simplified or broken down into smaller pieces.
Are there any potential bugs? Things like unhandled null values, missing input validation, off-by-one errors, or race conditions in async code.
Is there any duplication? If the same logic appears in multiple places, it might be worth extracting it into a shared function.
Are the names meaningful? Variable and function names should clearly describe what they represent or do. A variable called d does not tell us much, but discountAmount is immediately clear.
How we give feedback matters. I try to be specific and constructive. Instead of saying "this is wrong", it helps to explain why something could be a problem and suggest an alternative. For example, "this function is doing too many things, maybe we can split it into two functions, one for validation and one for processing."
It is also good to point out things that are done well. If someone wrote a clean solution or handled an edge case nicely, mentioning it encourages good practices.
On the other side, when receiving feedback, it is important not to take it personally. The review is about the code, not about us. If a reviewer suggests a change, it is worth considering even if we disagree. Sometimes discussing it leads to an even better solution that neither of us originally thought of.
Code review takes time, but the time spent is almost always worth it. The quality of the codebase improves, the team learns from each other, and fewer bugs make it to production.