Isn't it funny how developers tend to rely so heavily on manual and automated testing to check the quality of their code, while oftentimes neglecting an equally effective solution: a fresh pair of (human) eyes.
Code reviews are the systematic examination of other developers' code. Any developer team should incorporate code reviews into their software development process. A great code review leads to better software and a better team too.
To be more specific, code reviews result in fewer bugs, improve code readability, and keep style across the codebase consistent. They're also a great way to share knowledge across the team. After all, it's hard to know how other developers solve problems when you're only ever reading your own code.
In addition, code reviews can be a great way to mentor junior developers too.
Not only because more senior developers will review their code, but also because they will review code written by more experienced developers, a great way to quickly improve coding skills.
The above being said, not all code reviews are created equal. The quality of a code review will depend on the behavior of both the reviewer and the person whose code is being reviewed.
What Makes For a Great Code Review?
Let's cover the basics first. A code reviewer should examine the correctness of the code and its test coverage. They should confirm whether the style guide and best practices are being followed, and they should point out unclear names, unhandled edge cases, and code that's over-engineered or hard to understand.
But what makes a code review great is everything around the code. For one, a great code review thinks about the necessity of the code change and how it will impact the rest of the codebase. Do we really need this change or will it introduce unnecessary complexity?
A great code review has great delivery too. When you're commenting, stay professional and positive. Be mindful of your language and target the code, not the developer. For example, compare "You're requesting the database too often" with "This code is requesting the database too often." The former sounds somewhat aggressive, because it targets the developer, while the latter doesn't, because it targets the code.
Additionally, as a reviewer, it's wise to pick your battles too. Everyone writes code differently; unless it's a critical error, there's no need to comment on every line of code you disagree with.
This being said, if you have a lot of questions about a particular piece of code, it's usually better to speak to the person directly to clarify things. If you stay empathetic (every developer tries their best) it's a faster and better way to discuss problematic code.
As a final and broader point, the best code reviews are those that keep on improving. Don't think of a code review as a fixed process. Periodically think of how you can make your code reviews even better. How can they take less time while maintaining the same quality? How can every code review be a great experience for both developers? How can you use code reviews to better train new developers?
