Today, we are going to talk about one of the most significant utilities in the programming business. It is the code review, which we may describe as time spent verifying a particular solution and implementation. One or more programmers can carry it out as soon as the initial work is finished or sometimes even during the implementation. A specific approach to code review may vary depending on the team’s decisions and priorities.
The reason the code review is so important is its role in assuring code quality and work consistency. We want to prevent any mistake to finds its way into the production environment, and an additional pair of eyes is a pretty solid tool to do this. As a social aspect, the regular and effective filtering of unintentional implementation helps the team learn their limitations and build confidence in their codebase.
However, today we will focus primarily on the reviewer’s perspective and things one has to consider when approaching the task.
Problem and solution
The first goal of the code review is the validation of the solution concept. This analysis stage is often underestimated, and programmers tend to skip it and go right into the implementation check. Nevertheless, I believe this part of the inquiry may bring the most value for time spent.
It is absolutely crucial to fully understand the problem and analyze the idea of the solution first. As a result, we may find some inconsistencies in the final architecture or even in the definition of the problem itself. When that happens, it is the earliest, and thus the most beneficial, moment for giving proper feedback to the creator of the solution. Therefore, we may either improve our perception of the assignment and proceed from that, or find the crucial flaw in the author’s thinking, hence speed up the arrival of the correct implementation.
Furthermore, that kind of comprehensive understanding of both sides of the equation cannot be overrated when we move to the next objective of the code review.
Implementation
When we know the issue and recognize the correct solution, the second goal of the review is verifying whether the actual implementation matches the accepted plan. During this stage, the reviewer should concentrate on elements potentially covered by the solution but missing in the code as that leads to an incomplete implementation and means that the author missed some use cases. On the other hand, the reviewer verifies elements present in the code but without correspondence to the accepted solution as that signals incoherence and renders the implementation unnecessarily complex. Both of these cases are something that should be fixed.
It is worth to mention the importance of the review being conducted by a different person than the creator of the solution. Of course, the author should also examine the implementation before submitting it to verification. Still, the programmer who is writing the code has an impaired ability to look at it from a distance and notice errors, even the most obvious ones. Conversely, the reviewer does not have this deficiency, and thus the code review conducted in this manner becomes much more profitable.
Readability
The third necessity of every code review is to ensure that the final implementation is readable to any future reader that needs to study it. From the reviewer’s perspective, it is crucial to imagine someone who reads the piece while integrating a corresponding module or changing the logic itself. This person has much less information than we have during the verification process. Throughout the review, we know the problem, we know the solution, and we see the difference in writing. All of this gives us an edge in reasoning about the implementation.
In the end, the same code has to be readable on its own without the context regarding the current task. That’s why, it is essential to have in mind the programmer who will read it in the future.
Final touch
Code review is basically a simple yet powerful process of verifying the idea and implementation from another point of view. That’s why, it is crucial to understand the concept behind the solution and pay attention to the correctness and readability.
One last hint that may help with the review is to always give some feedback. Of course, some technical, standard, quick reviews may require nothing but acceptance, but it is good to provide some comments whenever there is anything more. Those may be a description of the overall solution, some remarks regarding an implementation detail, or even a technical compliment. Whatever it is, it provides the author of the code with a different point of view and allows comparing it to one’s own intention. Sometimes that brings an extra value to the process — an outer final touch.
All in all, that is why the code review exists in the first place. Cheers!