Code review is one of the most underrated processes to increase code quality. There is still resistance to a process that is seen as unproven and associated with useless overhead. However, by understanding how code reviews can work, it becomes clear that the advantages far outweigh its costs. I am here to directly address the most common concerns and to share a vision for the future of code reviews.
Spoiler alert: it’s not a fancy AI tool that replaces developers.
Now, any developer worth their salt is going to be checking and documenting the code over time. This is a given. There are many stages throughout development where bugs and mistakes are found.
This is why you have specifications and run tests.
So how do you arrive at the return on investment (ROI) of a code review?
Return on investment is hard to measure
Full transparency: it’s not easy to define adequate metrics to find out a code review’s ROI.
We do know some things. For instance: fixing a bug in the testing stage costs you on average almost eight times as much as if you catch it before. And if it’s ever found after the product has shipped? Well, that’s about 15 times as much.
The benefits of code reviews permeate the entire development process. It improves communication, the sustainability of products, the onboarding of new joiners, and a number of other issues.
Of course, if you want to kid yourself, you can try to put a number on it.
At the end of the day, though, we need to be comfortable with the idea that a formula will never capture how important code reviews are as well as the people in your team. It’s all about continuous improvement – and that’s an integral part of a team’s culture.
Understanding code reviews is simple
Sometimes, the major roadblock for teams to engage in code reviews is that they don’t fully understand what it means. As a developer, that resonates a lot – code reviews are time consuming, are typically unstructured and it’s quite easy to get lost in the process because of their cognitive complexity and frequent context switching.
So, how can we get more structure into it?
Properly done, here’s what an experienced reviewer will be looking for:
- Design: the code must fit the purpose for which it was created.
- Functionality: the code must behave in the intended way.
- Complexity: simpler is usually better. Both for functionality and for maintainability.
- Tests: there must be tests in place with sufficient coverage of the changes.
- Naming: variables, classes, methods names need to be clear and self-explanatory.
- Style: the code must respect the engineering guidelines of the company.
- Documentation: it must be updated, and it must be relevant.
This strategy is in many ways a methodical and rigorous process to improve code quality. However, in practice, valuable code reviews are not box ticking – the main goal is to collaborate and improve the codebase which is the common working environment for developers.
Code review brings in different sets of eyes to look at your code. Think of it as a manuscript, and of the reviewer as a proofreader. It’s a brand new set of eyes, someone likely unfamiliar with the text, and someone that needs to understand it on its own merits.
The author shouldn’t need to be at the reader’s shoulder, explaining what is happening in the story. In the same way, a code reviewer constructively should point out when your “narrative” doesn’t make sense. This way, reviewers and the author collaborate on the best solution.
This is a job for humans and adding automation helps but in the code reviews that matter, you ultimately need human interaction to reach the best outcome for the team.
Code review will help your team do its job
By talking with hundreds of developers, we have learnt that teams with a strong culture on code reviews are able to communicate effectively. Not just sporadically, consistently. This is because code reviews don’t simply fix bugs, they also ensure that the codebase is clean and easily understandable for others to maintain.
As developers get used to comprehensive code reviews, they will start changing how they code accordingly. This means code becomes easier to understand by others and a lot of time is saved going back and forth within your team.
(especially if your team is remote)
Most of us are working remotely at the moment, due to… ahem… current events. What we are starting to come to grips with is that some kind of remote work environment is not going away. Ecommerce in particular has been the canary in the coal mine regarding this issue. Consumers and companies alike have realised that there are a lot of advantages in working and buying from a distance, and in-office work will probably never revert to its pre-pandemic levels.
That means effective communication is now at a premium.
High quality code reviews help teams build codebases that facilitate communication, and that lets people get straight to work with very little synchronous guidance.
Are code reviews a silver bullet?
Simple answer: no.
What if the original code is a huge incomprehensible mess? Won’t reviewers spend hours on end trying to figure out how to even begin to understand the changes? Probably.
The complexity of the review itself increases exponentially with the number of changes, the maturity of the codebase and the lack of expertise of the reviewer. However, somehow this complexity feels artificial at times and we believe that has to do with the interface most reviewers are using right now. It is just a textual diff between files.
We started Reviewpad because we believe that it should be possible for developers to have the relevant information about code changes out of the box. Ultimately, we want to systematically help developers create an intuitive guide for reviewers to dramatically reduce the number of useless interactions required today.
There’s also the issue of communication and documentation which I will write about in the future.
We are working to make code reviews better
Reviewpad’s long-term goal is to make high quality code reviews easily accessible for teams of any size and working with codebases that might be recent or decades old.
And we want to do it by protecting our most important resource: developers. For that reason, Reviewpad is being built with a developers first mindset – it should make code reviews better by making it easier for developers to extricate themselves from bad code.
We are currently on private beta but if you want to hear more about Reviewpad, book a demo and we will show you how we are building the future of code reviews.
Top comments (0)