You’ve probably already heard of code reviews. Would you like to better understand the principles of code review, the benefits it brings and the important points to watch out for to ensure that it takes place in good conditions? That’s what this article is all about!
The principle of the code review is to have one or more persons reread parts of the source code written by another person. This is part of a process of continuous improvement of the code and its quality. There are a number of objectives when setting up a code review:
In 1976, Michael Fagan theorised and studied the benefits of code review processes, highlighting gains in productivity and bug detection. Indeed, as good practices are better understood and problems identified earlier, it is easy to imagine less time being spent on bug fixing after the fact.
As with any practice, code review can be counterproductive if it is poorly executed or misunderstood by the team. For some people, the term “review” may suggest a control or monitoring modus operandi aimed at making negative criticisms of the developers’ product code. It is therefore very important to clarifyand share the objectives with the whole team, and to highlight the continuous improvement process.
Team spirit and culture will strongly impact the way code reviews are conducted.
The prerequisites that we consider indispensable are those defined by the 10 Commandments of Egoless Programming, taken from Jerry Weinberg’s “The Psychology of Computer Programming” (1971). Although their presentation will be the subject of another article, it should be remembered that these commandments aim to improve collaboration between developers, by detaching one’s “ego” from the code produced.
The code is a collective property and each developer must be open-minded, humble, take a step back from his code, empathize with others, and know how to accept if other people propose better decisions than his own. This sounds like common sense, but their application is far from systematic!
Each team will adapt the frequency of code reviews according to its needs and context. For some, they will take place systematically each time a development branch merges (Pull/Merge-Request). For others, they will be more punctual (once a week) on more central parts of the code. In all cases, there are certain best practices to follow, both for the submitter and the reviewer:
If the pattern often found in a team is that the “Tech Lead” profile is the only person to proofread the code, it is also relevant to invite each person to participate as a proofreader. After all, everyone can contribute his or her own vision and new ideas, whether junior or senior. And even if you are a senior, you should always strive to improve and no one is infallible!
A related objective of the journal is to strengthen communication within a team and to facilitate the development of developers’ skills. It is a very good exercise in dialogue and sharing that reinforces cohesion and well-being within the team. Reviews are also very revealing of each person’s “soft skills”. The success of a project depends mainly on healthy and productive exchanges between each stakeholder.
A study conducted at Google in 2015 highlighted the key performance factors of a team. Beyond criteria such as experience and qualifications, the main factor that emerges is that of psychological security. It reflects the comfort and ease with which developers are comfortable talking openly about problems in the presence of other people in the team, as well as taking risks and initiatives. If there is trust in a team, each person feels freer to act without fear of the reaction of others, and especially without the fear of failure. Practicing code review also means establishing this psychological security which has so many advantages for a team!
Finally, we mentioned above that code review increases the knowledge of the code within the team. Have you heard of the Bus Factor? This is the number of people beyond which your project cannot continue in a viable way if they are hit by a bus. It is a way of illustrating the concentration of expertise within a team. By inviting each person to reread code they have not written, and thus to appropriate other parts of the code, this knowledge is better distributed within a team.
Still doubt the benefits of code review? If it is applied properly, this practice brings obvious gains to the whole team. Our Promyze platform offers precisely the Craft Workshop format, which are collective review formats with the aim of focusing on the definition of best practices. Based on team discussions and decision-making, the Workshops meet all the objectives of the code review, while consolidating team cohesion.
Promyze, the collaborative platform dedicated to improve developers’ skills through best practices sharing and definition