At 1904labs, code reviews are an integral part of our process. We strongly encourage every team to make reviews part of their Agile Team Agreements. We recognize the importance of code reviews – not only to the product we deliver to the client, but also to the growth of every developer.
Why Review Code
The two biggest illusions about code reviews are that they will guarantee bug-free code and that someone with more experience than the author should review the code. Bug squashing isn't even the most important output of code reviews. Yes, you might catch a few bugs when reviewing code, but a developer worth their salt should have done a decent bug pass of their own before submitting the code for review. And limiting reviews to just the more experienced developers adds more work for them and keeps the others from gaining the same experience. The reality is: Code reviews are for the benefit of the developers on a team.
When reviewing code, everyone can learn something. No matter how senior you believe yourself to be or how familiar you are with a language, framework, or code base, you benefit from reviewing just as much as the code's author. It is a critical part of the role of any contributing developer on a team.
How to Review Code
Now that we've covered why your team should review code, here are a few ideas to make reviews more helpful, keeping growth of the team's developers in mind:
Start with a question
When you run across code that doesn't look right, you can start by assuming the author knows something you don't. Seek to understand why they chose to approach the problem a certain way; ask what were the requirements for the change; challenge them on if they believe it's the best way to complete the task. Of course, this isn't necessary for an obvious bug, but you should consider asking any time there is uncertainty.
By asking a question, you give the code's author the chance to think and respond and you get to learn from them. A question encourages the author to inspect their work and either learn from a mistake or take the chance to explain and teach about their code. Part of growing as a developer is knowing why you wrote the code and being able to defend it and your decisions; answering reasonable questions about that code gives you a chance to build that skill.
Be empathetic
Everyone has a different background and path to who they are today. No one had the same opportunities, education, or experiences. Be mindful and tactful in your review comments and consider your audience before writing your response. A well-worded comment that seeks to share and build, rather than criticize, will better serve the project and everyone involved.
If you're an experienced developer reviewing code, this is a chance to share your experience while keeping an open mind about the author's technique. Part of your responsibility is to be a respectful mentor and help grow the other developers around you. With a thorough review, you can find ways to help them grow, but also learn new tricks and practices they have picked up from others.
On the other hand, if you are reviewing a more experienced developer's code, you will learn a lot during a review, but it is still important for you to give feedback and help the author continue to grow.
Make criticism constructive
Since the purpose of a review is to elevate both the reviewer and the author, don't be satisfied leaving a critical comment and moving on in search of the next mistake. "This is wrong." does not benefit anyone, but "Maybe something like this would be better," followed by an example, gives the author a chance to examine an alternative and come up with a better response.
And when making the review, take some time to research potential alternative solutions to build a good example and share your sources along with your suggestion. Not everyone will approach a problem in the same way and sharing how you research can be just as beneficial as proposing a fix. The research will force you to grow and then both you and the author will benefit.
Be thorough
A good code review takes time – sometimes a lot more time than you expect. A quality review requires you to take the time to understand the code base, the changes, and the requirements in order to give the best responses. A rushed review will miss potential defects in the code, increase the chance of miscommunication, and prevent you from gaining a better understanding of the code base and the problem being solved.
For a medium-to-large sized code review, set aside at least an hour to give yourself a chance to digest the code and make helpful comments. It will take multiple passes to fully understand what's going on and give the best review. Also, keeping that time available gives the author a chance to follow up with you and to develop a solution together.
Grow Your Team
Reviews don't have to be painful, dragged-out experiences. They're not a time to exercise egos or establish dominance. Code reviews are the best chance for you and your team to help each other grow into better developers.
.png)
