Story by: Marisela del Valle — Backend Lead at Grability
Most people who work in a software development team have to deal with this activity named “Code Review”. Let’s start by defining this for those who don’t know what it is: Code Review is an activity that takes place in software development teams where team members review another team member’s code.
It is very common that some people don’t feel comfortable with their coworkers reviewing their code, especially when they have more experience or a higher position. Even, many times, people with leadership positions or with more experience use to be rude when they review code of those who have lower positions or with less experience. For example, when doing comments about a “badly written” code, or fragments of code that can’t be understood. Those behaviors make the person that implemented the code to feel bad judged and afraid of getting their code reviewed.
A couple of years ago, when I was a junior developer, I had the opportunity to get my code reviewed by people who knew more than I did and were experienced than I was. I remember having that big sense of fear before sending my code so that it could be reviewed and, honestly, it didn’t feel good at all.
Because of this, it is necessary to bear in mind some important aspects when doing Code Review:
How to do Code Review?
- Ask questions or give suggestions instead of imposing or giving orders. For example, you can say “instead of creating this large method, I would have created two methods apart”.
- Ask for opinions: “What do you think about changing this class name from ABC to XYZ?”
- Talk about “us”, instead of “you”. This reinforces teamwork and helps to remember that, all together, we want to build better software. For example, “we could create a class that does X thing”.
- If something’s wrong, say why and give examples. It’s very different to say “this is wrong” than “this doesn’t solve the problem because… We better do it another way”.
- Remember the seniority of the person who is having their code reviewed. It’s important to take into account that people who are less experienced, maybe won’t give the best solution to the problem they are solving.
Why do we do Code Review?
- To find the best alternative to solve a problem
Many heads are better than one. Probably the development work you did has more than one way to get solved, but this doesn’t mean that it’s wrong. The important thing is to hear all the opinions, to be able to debate and to take the decision of which would be the best solution to that problem. Between two or more people could find the most suitable solution.
- Learn to read code
It’s not easy to read other people’s code. It is much more simple writing code, than reading it. The best exercise to learn this is by doing Code Review because, to make a good review, we must read the code that someone else wrote and understand what we are reading means.
When there are different opinions about the implemented solution, there must be an agreement. Everyone may not agree and it doesn’t mean that an opinion is right or wrong.
We need to have conversations and understand other people’s point of view since it is not about who makes something better, but what is better for the project.
- Check that the implementation can be understood
The people who wrote the project’s code you are working on, won’t be there forever. In order to have maintainable code, it has to be written in a way that, when it is read, it will be understood. Not just for the one who wrote it, but to anyone that needs to check it out. We have to learn to write code for others, not for us.
It is about work, don’t take it personal
It is important to make clear that comments shouldn’t be taken personally since, at the end of the day, it is about work. If you are leading a software development team, it is important to be tactful during the code review process. If, on the other hand, you are a developer, see those comments as an opportunity of improvement and don’t take it personal. Sometimes we all believe that there’s no other way to do things or that we made our best effort and this last comment could be true, but most of the time we can do better. At the end, it’s about giving the best contribution so that everyone involved can learn, have a readable code and the most optimal solution possible.