by 
Code review is not a new fancy process. In fact, it is an essential part of a high-quality codebase with little to no technical debts.
However, the mere code review does not assure a good quality codebase, lack of it certainly is a strong indicator that the codebase is disastrous with high technical debt. So the code review process should not be taken lightly and in my humble opinion, the more rigid code review process, the better.
In this article, first, I explain my reasons based on my experience why a rigid code review process is an absolute need to have a high-quality codebase and a healthier team. Then, I provide my definition of a good rigid code review. And lastly, conclude the article of how some individuals wrongly see code review as a wasteful practice.
Benefits of a rigid code review
Less buggy codebase
While code review does not prevent all bugs to happen, it significantly reduces the occurrence of bugs. The earlier catch a bug the better is it. As it is less expensive to fix. A simple code review can prevent many bugs that cause by reckless programming to slip through. Let see an example of it:
String senderEmail = "[email protected]";
String receiverEmail = "[email protected]";
if ( senderEmail = null ) {
throw new SenderEmailCannotBeEmptyException();
}
if ( senderEmail == receiverEmail ) {
logger.info("Sender is the same as receiver");
}
As you can see there are two bugs in ten lines of code. Without a code review, in the best situation this bugs will be detected at the manual testing stage if it exists, or worst they will go all the way to the production. And once the customer found out, the team has to do fire fighting by releasing and deploying a hotfix.
Less technical debts and code smells
A rigid code review reveals the fragile part of the code and avoids bad practices as well as anti-patterns. This generally improves the quality of the code and reduces technical debt. For instance, a code review can reveal parts of codes that are not tested, which most probably would not be testable without refactoring.
Additionally, the code review forces developers to respect the coding convention.
Positive psychological effects
A rigid code review encourages developers to interact with each other. This is a very positive thing in the case that some individuals work in solos.
A good code review process increases interaction and collaboration level among team members. And in long term team members form a deep bonding to each other which as a result increases the team confidence as well as productivity of the team.
It also reduces the level of arrogance of some team members. When even the most top guy’s code is not safe from getting graded by his peers.
Knowledge distribution
A good review process helps individuals who are not working in a certain part of the project to get involved and learn about it. This greatly helps in knowledge distribution and avoids a single developer to solely holds knowledge of certain parts of the code. Hence, if a team member leaves the project, others can take over at a pretty fast pace.
Learning
A good review not only gives developers new perspectives on how putting things together but also is a good learning resource for them. This is a two-way street, both reviewer and reviewee have a chance to learn from each other. It is super beneficial for teams that have some experts.
Definition of a good rigid code review
So far I discuss the benefits of having a good code review process. But I have not defined what a good and rigid code review process is. In this section, I provide a definition of it.
A good code review process should not be gameable. Means, it should not be defined in such a way that after sometimes developers game the system and just do it for formality or for sake of having it. To minimize that it is good to have some ground rules. Here I noted the ones I can think of:
- Dedicate a 30 minutes time in the morning to the team members to review whatever left
- Define a minimum number of approvals needed for a pull request to merge (usually 2/3 of reviewers is a good ratio)
- Review tests with the same importance as code
- Have an odd number of reviewers to break the tie
- Make small pull requests, so it can be reviewed in a short period of time
- Instead of commenting ten paragraphs go and talk with the developer directly
- Code review as if tomorrow you have to maintain the project
Code review misconception
One thing important to note is code review is not a waste of time and/or resources process as some may see
Yes, it is an extra overhead for the team but in a long run, the team will not need to spend a tremendous amount of time to fix bugs. Moreover, adding new features to the project will be less time-consuming as well as less buggy. It also reduces the chance of introducing regression bugs. And more importantly, you will have a happy team of developers who are working in good harmony.
Conclusion
In this article, I discuss the importance of having a rigid and good code review process.
Of course, what I stated in this article is coming based on my personal experience which I wanted to share. And it is natural that the culture and dynamic of each team is different. What mentioned here might not be totally applicable or even make sense in some companies and/or teams.
