Meaningful Code Reviews

When I started reviewing code — early in my career — I felt unproductive. It wasn’t clear how I was contributing to the product without writing code. I only did code reviews out of tradition, something you do before merging changes. Since then, my perception of code reviews has evolved from a soul crushing tradition to an opportunity to learn and improve the code quality.

Code review is a great learning opportunity, especially for junior developers. I have learnt a lot about software design and common mistakes from giving and receiving reviews. You can also learn a lot about a team from their code review comments. The next time you join a team, go through the comments in closed pull requests, a treasure trove for understanding the product and team dynamics.

The first time I reviewed code I felt lost. I didn't know where to start or what to look for. But I have grown and left my childish ways. Now, I first check whether the changes fulfil their purpose, does it do what it is supposed to do? Other times, I am tempted to check for code style violations but this is not the best use of my time. To avoid the temptation, I advocate for the use of linters and formatters like tslint and prettier.

After confirming that the changes work and do not introduce defects, I shift my focus to the design. Software doesn't become spaghetti over night but through innocent acts of ignorance. I scan the code to see where duplication might have occurred, then I make sure that we haven’t broken any of the SOLID principles or that we’ve broken them within reason. I also look for opportunities to improve the code with design patterns or with the framework’s or programming language's idiomatic implementation.

The other thing that I care about in code reviews is names. Most of the time we don't care what we call things until we have to read them in the future. I make sure that the names communicate their intent, are meaningful and can be pronounced.

During code reviews, I aim for respective collaboration as it is easy to let your frustration leak through your review comments. Understand that the author takes pride and feel validated by their work, so criticise cautiously and politely, after all, the bugs are the bad guys not the author.