Things every developer should know about code reviews

Being a professional software developer requires a lot of practice and learning. Some people – including myself – believe that one of the most interesting ways of learning and improving our coding skills is by reading other people’s code. We often refer to this process as a code review session, and it can be used by teams of any size during their development process. In the next sections, we are going to explore some of the benefits of code review sessions
and also some of the challenges that they can present to teams, even for the most experienced ones.

I believe the first and main benefit of code review sessions is that they allow other people to ask questions about your code and make you think twice about the decisions you have made. Your code can be validated not just for obvious mistakes, but also for its design. Martin Fowler once said that refactoring is all about economics. The less you care about the design or architecture of your system, higher the chances you spend too much time and money with the upcoming changes or features since your code base will be rigid and, therefore, difficult to change.

Another important aspect of code reviews is that they can also share knowledge by eliminating the idea of “owners” of a piece of code. This makes more than one person accountable for a particular part of the software. The whole team can benefit from this
practice: on one hand, experienced developers help the less experienced ones understand what makes a good software design and how they can improve their code, normally by using industry standard patterns and practices. On the other hand, those same experienced developers can learn and improve because code reviews are supposed to be less about teaching and more about having a productive conversation.

But code reviews can also pose challenges. Since they are all about communication, things can go wrong. Writing code is, in general, a creative task and makes some developers proud of their work. This can lead them to take a defensive stand, taking criticism and feedback
personally and even take offense. Depending on the communication skills of the code reviewer or code review team, it can be really difficult to be objective and clear about what needs to be changed. I have seen many experienced developers tending to force changes in a way they feel comfortable with, asking for code changes that sometimes can be interpreted as nitpicking. Nitpick code reviews are those where the proposed changes often point to things
which apparently are a matter of personal opinion or preference and not necessarily something important for the project or situation. This may cause conflicts between team members and in some extreme cases, lower the overall morale of the whole team. Another risk might be in the opposite situation: having superficial code reviews is bad because low-quality code can go unnoticed. This can happen for different reasons, including lack of time or interest from team members.

Finding the right balance between productive code reviews and nitpick ones can be challenging. Nevertheless, it is a good practice and I strongly recommend it. Get together with your team, share these ideas and discuss code reviews. I also suggest you set some time to read some other excellent blog posts about code reviews and other practices to help you improve the quality of your code.

Good reads to inspire you and your team about code reviews:

Why code reviews matter (and actually save time!)

Pairing vs. Code Review: Comparing Developer Cultures

About the author

Eduardo Brasil, Software Engineer at PoaTek.