Many only see code review as that ultimate step to go through to get code changes merged in. That step where some of your peers will go through your changes to make sure there is no error in the code.
While getting someone to check your code is definitely one of the main benefits of code review, there is actually much more to it. It is just that some of the benefits are less obvious than others. Let us go over them.
Reducing the risk for technical errors
As mentioned above, this one is probably the most obvious benefit of all. Ideally, you would get someone unfamiliar with the feature you implemented to review your code. Someone unfamiliar with the feature will have a fresh look on it and may approach the problem from a different angle, which should increase the chances to detect an error you may missed.
Confirming the validity of the implementation
An implementation can be technically perfect while completely missing the point. Coding is such a fun activity and it is easy to get carried away and lose sight of the actual end goal. Most of us write code to solve given problems. Code review gives us the opportunity to have another pair of eyes confirming that the code we wrote handles all the aspects of the targeted problem. The last thing you want is to have code running on production that perfectly does the wrong thing.
Alternative design and potential optimizations
Advanced code reviewers will always look at the big picture before looking into the details. They will first identify the targeted problem, the design you implemented, and evaluate how suitable and optimal that design is. If the design you implemented happens not to be optimal, advanced reviewers will propose alternatives, explaining why the alternatives are a better fit than the design you originally thought about.
In most cases, a rough implementation of the optimal design beats the optimal implementation of a rough design. Advanced code reviewers know that and it is one of the first things they will be checking when reviewing code.
Spreading domain knowledge
We usually write code to solve problems. These problems are the reflection of the context your program runs in. We call that context “domain”. Your program and its domain are in constant interaction. Your program reads its domain and takes actions to affect it. Similarly, changes in your domain can trigger actions in your program. Therefore, changing the behavior of your program is the expression of an evolution of that relation.
By getting other people to review your code changes, you expose them to future changes of the domain. To review given code changes, one needs to understand the context. Why are we changing our program that way? Why did we pick this value and not another one? All these are questions one will need to ask themselves when reviewing an implementation. As a result, even if the reviewer was not involved in the 7 discussions about that new feature, and did not read the 15 pages of the related design document, after reviewing the code changes they should be familiar with most of the details of the feature.
This can be especially valuable in a context where the team is in charge of multiple projects. For example, it could be a good thing to ask a review to someone not actively involved in the project; this would allow that person to stay somehow up-to-date about the evolution of the project without actively working on it.
Education
We — human beings — understand concrete topics more easily than abstract ones. Code review sessions are golden opportunities for us to discuss about technical topics and share knowledge while looking at concrete examples.
Code review can create situations where it is easy to discuss and share knowledge within an organization:
- senior engineers/developers get the opportunity to give concrete feedback to more junior engineers/developers
- junior engineers/developers may have wonders and unknowns about general concepts that they can’t express with words. Code review gives them an opportunity to leverage concrete examples and ask questions relevant to their growth
- engineers/developers with different experience get the chance to share their point of view on specific situations. And we all know diversity is a good thing, right?
- engineers/developers with roughly the same level of skills and experience get an opportunity to debate on given topics, which could lead to a valuable outcome
- etc
Leveraging different environments
I don’t get it. My code changes work perfectly fine on my computer but they fail in the development environment.
I am pretty sure you have heard this one at least once, haven’t you?
Someone reviewing your code changes will hopefully pull your code changes to run them on their machine at some point. Or, even better, your team has CI/CD pipelines set up to run automated tests when your code changes are in review. Code review will give you the opportunity to get your code changes to run in different environments, letting you confirm they work as expected regardless of the environment.
Some advices to make code review a pleasant experience
Despite all the benefits mentioned above, code review can be a scary experience to go through. It is unfortunately easy to take it personally when someone points the finger at a mistake you made, and it is easy to get emotionally affected by that. After all, you wrote some code with errors in it and it got flagged and exposed to others. Who would like this? But things do not have to be this way. Instead of seeing code review as a process where you are being judged, try to see things this way: the entire team needs something to get done; you are the one who took the responsibility to prepare that something and now the entire team is simply making sure the implementation is as good as it can get. The code you wrote is as much the property of your reviewers as it is yours. After all, once merged in, the code will become every one’s responsibility. Therefore, it is every one’s responsibility to make sure it is as optimal and as safe as possible before getting merged in.
In that regard, here is a short list of things to keep in mind during the code review.
For the author:
- stay open to feedback. Understand and accept the fact that there might be better solutions that the one you came up with
- everybody makes mistakes. You are not the first one and you will not be the last one. Do not feel offended when someone points out flaws in your implementation, regardless of the gravity
For the reviewers:
- be grateful. The code changes are common property, but the author is the one who used their time to make it happen
- if something looks particularly great to you, do not hesitate to mention it. It motivates the author and it gives others examples of good implementation
- when you encounter something that looks obviously wrong to you, ask about the reasons and the background first. There could be something you missed
To both the author and the reviewers:
- remain open and objective. Do not forget: the changes you are discussing are common property. The goal is to get to a solution everybody is satisfied with. It is certainly not to go through a crazy back-and-forth or to prove that you are better than others
Experience has shown me that once everyone adopts this mindset, the code review process becomes such a pleasant and valuable experience. It strengthens the bonds between the members of an organization and greatly increases the quality of the work the team produces.
