Code reviews—a vital part of software development, but one I used to dislike intensely. Often, code reviews didn’t provide much feedback, and as a junior developer, the instructions would be clear (if I was lucky) but rarely the reasoning behind them. I remember how frustrating the whole process was back then. I promised myself that if I ever found myself on the other side of a code review, I would ensure that whoever read it understood what I wanted and, more importantly, why. Because, dear senior devs, “This doesn’t look right, please change it” is not exactly helpful. How? Why? Will it break the functionality?
These days, as I prepare code reviews myself, I try to avoid making my juniors feel as lost as I did. Here are a few tips and my personal 5-step approach to effective code reviews.
Step 1: Understand the Intent of the Code
For me, code review starts with analyzing the task and the issue. What’s it about? What new functionality is being introduced? Why was a refactor necessary? These are all critical questions I answer before even looking at the code.
Step 2: Focus on Readability
I like code that’s readable. My goal is to quickly understand what each variable represents, the aim of each method, and why a particular class was introduced. I avoid vague variable names like x, y, or z—those belong in mathematics, thank you very much! If I encounter a long, complex function, I’ll suggest splitting it up, renaming variables, and explaining my intent. I definitely don’t limit myself to “This is wrong.” I want the developer to understand why I’m making suggestions.
Step 3: Tests and More Tests
For code review, test coverage is essential. If new functionality is added, it’s time to write tests. If something has changed, the tests need to change too. And if it’s a refactor? Well, the original tests might deserve some attention too. I also make sure to check if the changes haven’t disrupted existing functionality.
Step 4: Provide Constructive Feedback
It’s important to me that a code review is more than just a pile of comments. If I don’t like a solution, I discuss it with the developer to understand why they approached it that way. I present my suggestions as options—not as absolute truths.
Step 5: Keep the Dialogue Open
Code review is a two-way process, so I always give my colleagues the chance to respond to my comments. If they use a less conventional approach, it’s a great opportunity to discuss it—it often broadens my own perspective!
Tips and Tricks for a Smooth Code Review Process:
- Templates: I use a code review template with clear criteria, which helps keep my feedback consistent. I focus on clear naming of variables, methods, and tests, ensuring uniformity, and looking for optimization opportunities.
- Testing Focus: Test coverage is crucial, though I don’t insist on 100% coverage. I just want the functionality to be well-tested.
- Take Breaks: I almost never do a code review in one sitting. Taking short breaks allows me to keep a fresh perspective, making sure I don’t miss important details.
- Balanced Feedback: I aim to provide both positive and constructive feedback. I know there are always parts of the code to improve, but I want to avoid coming across as a critic. I want juniors to understand that I see the effort they put into the code, and I’m here to support them as they learn and grow.
Conclusion
Code review is an incredible tool, one that deserves a solid place in the development process. It’s essential to see it as a constructive feedback loop and avoid letting personal biases take over. For juniors, it’s an invaluable motivator, a tool for discovery and learning. For seniors, it’s a way to maintain code consistency and help elevate the entire team’s work.
Steve says
That’s good