Are code reviews really a waste of time?
By: Juan Manuel Ruiz Holguin
Tags: Merge Request, Code Review, Continuous Integration, Best Practices

Have you ever heard “Code reviews are a waste of time”? or have you ever felt that code reviews are of little use?

Being totally honest, I have experienced both situations. Throughout my career as a developer, I have come across colleagues who weren’t entirely comfortable with Code Reviews and even myself have had the feeling that they were of little use. Usually, the tensions around code reviews have more to do with underlying team dynamics than about the process itself. For example, senior developers might feel threatened by having their code reviewed by juniors. It’s human. Another factor is the last days sprint rush, where code reviews can feel like a blocker to completing all the tasks from the sprint before the end. Finally, code reviews also bring folks to give feedback about each other, something that introverts can find challenging in the wrong environment.

But over time I have realized that the problem is not the Code Reviews but how we approach the code review process and how we do them.

I am a front-end developer, senior if you see my experience. And from my point of view CR add great value, both to me as a developer and to the quality of the code.

I’ve worked in several companies and in a lot of teams. My code has been reviewed by very experienced developers and junior developers, and I have to say that I have learned a lot from all of them in the Code Reviews.

For that reason this article is not intended to support the idea of that a Code Review is a waste of time, quite the contrary. In our team, we think that the Code Review or Merge Request are a very good practices and that they contribute much value to the developer implementing the code, the reviewer and the company. Why do we believe that? our experience has demonstrate that a good CR can avoid problems, increase the quality of code and tests and help us to share knowledge across the teams. There are a lot of articles and studies that explain the benefits of the Code Review, here some examples : A Case Study at Google], Addy Osmani and much more.

But we will only achieve this by dedicating the attention and effort it deserves, changing the way we see this process and applying some simple recommendations. In this article, we dive into some of the thing I have implemented or helped implement since I joined ING.

Photo by NESA by Makers

Changing the mindset

The first step in making PR work for everyone is changing our mindset, considering code reviews as part of the development process, both at the software and product level.

We must be aware that public relations are part of the development process. It is one more stage (such as QA, automatic tests, …) and, as such, it must be taken into account when estimating the task. Be it a feature or an arrangement. And this, which seems so simple, we often forget. We think about the complexity or not of the implementation that we have to address, whether we know that part of the application or it is the first time that we are going to work on that part, … But often, we don’t take into account that our development must be reviewed by our colleagues, that we may have to make changes and this takes time. Time to include in our estimate.

To give visibility and be more aware of time occupancy code reviews, if we use agile methodologies in your development process and a board, it may be useful to add one more column to our board. In this way, the entire team, including the stakeholders, will be aware that for the development to be completed it must go through a necessary stage which is the validation of the code.

This change of mind is necessary not only when you are in the role of author, but also when you are a reviewer. As reviewers we must be aware of how important our development task is as reviewing the code of our colleagues. We have all heard at some point: “Sorry, but right now I don’t have time for your PR.” Think that reviewing code not only helps your colleague finish the task, but also participates in the development process, helping to maintain a cleaner, more maintainable and scalable code.

The job of a reviewer is not only to look for possible errors in the implementation, but also a way to learn from your colleagues. We each have a vision and a way of doing things, but we must all try to make our developments maintainable, scalable and meet company standards.

A Code Review is also a form of knowledge between the people involved.

We should see Code Review not just as a way to get cleaner and more maintainable code, but as a place of learning and where to share and discuss ideas or ways of doing things.

Good practices as an author

Avoid large pull requests.- Avoid making Pull Requests that are too long. Advantages:

Facilitates the work of the reviewers , making the review faster and reducing code integration time.

, making the review faster and reducing code integration time. The intention is clearer and it is easy to detect errors, if any.

and it is easy to detect errors, if any. Facilitates the integration of great features. For example if the code can be activated or deactivated by a flag.

2. Provide context.- Not always necessary, but when we work in large teams/applications and we have to review some code that is outside of our squad/team may be necessary to do it. Anyway it is usually a good practice to give context of what is intended with the development. A detailed explanation is not necessary, but it is necessary to tell what functionality is going to be added or why the current functionality is modified. What other parts of the application has been detected that may be influenced by this development … This, in addition to making it easier for the reviewer or reviewers of the Merge Request, can facilitate the prior detection of bugs, “If you modify this functionality it will also be necessary to modify the X because it can be affected in such a way.”. This step can be skipped if we stick to the first recommendation “Avoid Pull requests that are too large”.

3. Review your changes before opening the Merge Request.- Before opening the PR, review the changes you have made. It is not strange that you realize that what you left for later you finally did not commit.

4. Help to maintain standards.- If in the discussions there are topics that are not part of of your team/company, agree with your team to add them the the standard guide. In this way you (and yours colleagues) will avoid that same comment in subsequent Code Review.

Good practices as a reviewer

Assume competence .- Do not doubt the work of your colleagues. Maybe you don’t have the same context and/or knowledge. To avoid this type of situation it is good to apply the second recommendation “Provide context in your Pull Request”.

.- Do not doubt the work of your colleagues. Maybe you don’t have the same context and/or knowledge. To avoid this type of situation it is good to apply the second recommendation “Provide context in your Pull Request”. Focus on the code .- Comments should always be focused on the code, not on personal or critical perceptions. It should always be constructive and aseptic. The objective is to have generate the best possible code

.- Comments should always be focused on the code, not on personal or critical perceptions. It should always be constructive and aseptic. The objective is to have generate the best possible code Dont’t wait too much .- Do not take too long to do the code review. As we have said before, developing code is as important as reviewing it. This will avoid frustration and speed up the process.

.- Do not take too long to do the code review. As we have said before, developing code is as important as reviewing it. This will avoid frustration and speed up the process. Provide Alternatives .- When you consider that something is not correct, does not meet the standards or you simply have another vision of how to do it, provide alternatives. The provided alternative should be feasible, provide examples to clarify your comments.

.- When you consider that something is not correct, does not meet the standards or you simply have another vision of how to do it, provide alternatives. The provided alternative should be feasible, provide examples to clarify your comments. Justify your comments .- Justify your proposals, for example adding a link to the style guides, or official documentation, … Avoid using comments such as: “Incorrect, modify it”, “Change it! it’s not correct”, …

.- Justify your proposals, for example adding a link to the style guides, or official documentation, … Avoid using comments such as: “Incorrect, modify it”, “Change it! it’s not correct”, … Mark nitpicks and optional comments .- If the changes that you detect are not very relevant and do not contribute much but it would be nice to have it, mark them as such. Emojis are good for that kind of things: 💅 (nitpick), 🍫 (optional improvement), ✍🏻 (Add documentation), ..

.- If the changes that you detect are not very relevant and do not contribute much but it would be nice to have it, mark them as such. Emojis are good for that kind of things: 💅 (nitpick), 🍫 (optional improvement), ✍🏻 (Add documentation), .. Don’t make statements, ask questions instead. Questions are better that statement because, a statement is accusatory “You didn’t add test for this method”. But if you reword as a question “What was the reasoning behind this method is not covered?”, you are seeking for information.

Questions are better that statement because, a statement is accusatory “You didn’t add test for this method”. But if you reword as a question “What was the reasoning behind this method is not covered?”, you are seeking for information. Don’t use “Why” in your questions .- When you use “Why” it seems that your are asking for explanations or. Sometimes is very difficult but try ask questions avoiding the “Why”to reword to “What was the reasoning behind …” or something like that.

.- When you use “Why” it seems that your are asking for explanations or. Sometimes is very difficult but try ask questions avoiding the “Why”to reword to “What was the reasoning behind …” or something like that. Congratule on a job well done.- The last and not the least important, remember to congratulate on a job well done.

Conclusion

Going from feeling that code reviews are inefficient and painful requires an effort on our part. But, as we have seen, the steps to follow so that we feel that they are useful, efficient and necessary are not difficult at all. Following these simple steps will allow us to enjoy the Benefits of Code Review:

Sharing knowledge .- Reviewing someone else’s code helps us learn. Not only when we are reviewing code for a functionality that we have never touched before, but because it gives us a different vision of how to do things, it makes us ask ourselves questions: why did you use this pattern? Wouldn’t it be better to use this other one? But not only will we learn, if the person doing the MR is new to the team it will help them to consolidate all the information they have read in the project documentation.

.- Reviewing someone else’s code helps us learn. Not only when we are reviewing code for a functionality that we have never touched before, but because it gives us a different vision of how to do things, it makes us ask ourselves questions: why did you use this pattern? Wouldn’t it be better to use this other one? But not only will we learn, if the person doing the MR is new to the team it will help them to consolidate all the information they have read in the project documentation. Maintainability, scalability and clean code .- We love to use these three words when we talk about our developments. But we must remember that the code is not ours alone. Any development you do will be part of a set, the application. And that application has to be maintained by everyone. What you do today must be understood by the person whose turn it is to modify this code in a few months. The standards and practices of Clean Code to be used are defined by all of us. Therefore, the code reviews will help us to maintain those standards together. 4 eyes see more than two.

.- We love to use these three words when we talk about our developments. But we must remember that the code is not ours alone. Any development you do will be part of a set, the application. And that application has to be maintained by everyone. What you do today must be understood by the person whose turn it is to modify this code in a few months. The standards and practices of Clean Code to be used are defined by all of us. Therefore, the code reviews will help us to maintain those standards together. 4 eyes see more than two. Helps us grow.- Proposing alternatives in our comments forces us to think about these solutions. It also makes us put ourselves in the other person’s shoes and ask ourselves why they decided to do it that way and not another. In short, it takes us out of our comfort zone and helps us to have a broader and richer vision.

Resources