Code Reviews are a great way to use the experience and knowledge of a team to create good software. Not all review processes are enjoyable, though.
But there are a few things you can do to improve the process for everyone involved in it. This article is going to give you six tips that will definitely help you to improve your review process for everyone.
Make Expectations Clear
A good review process should both be standardized and individual. The terms of the process should be written down and transparent for everyone on the team. Each team member should know what is expected of them and all team members should agree on the terms. Changing the terms should always be a democratic process within the team. If the team disagrees on changes or terms, it should discuss the issues until there is consent.
On the other hand, the process should be flexible enough to allow for individuality. Reviewees should be able to ask for more in a specific review when they see the need for it. Sometimes, very important features or complex problems need more characteristics reviewed than usual.
Don't Demand Changes, Make Suggestions And Explain
To make a review an inclusive process, making suggestions is better than simply demanding changes. If reviewers simply demand changes without explaining why, they lift themselves a level above the reviewee and give them a feeling of having to justify themselves. This can go so far that reviewees stop using their own thoughts and style of problem-solving and instead use a way that guarantees them the most positive review experience. In the long run, this hurts the team and the product.
So, instead of stating "You must change this", it's better to go with "If we did it this way [suggestion here], we could solve issue x and y I can imagine arising when we further go down the current route."
Be Open For Discussions
A healthy discussion can do wonders. Individual issues found in reviews should be discussable. Every participant should have the chance to state their opinion and give reasons for why they think their solution is a good idea. Those discussions should go for as long as necessary until all participants can agree on a solution. No individual team member should have the power to simply end a discussion. A discussion is finished when it is finally solved and a solution can be implemented.
Eliminate Personal Code Authorship
All source code should belong to the whole team. No individual code ownership should exist. Personal code ownership can lead to developers taking criticism personally, especially in reviews. The whole team is responsible to create a good and maintainable product. Bad code is the mistake of the whole team, never of only one individual.
Developers create code on behalf of the team and reviewers ensure that the team's code meets certain criteria. Switching to this mental model of "our code", and not "my code", can enable developers to focus more on the overall goal and less on the personal aspects of being hurt when whatever they produce does not pass a review flawlessly.
Reserve Enough Time
A review should never be rushed. If it takes an hour of focused work to do a review, then be it. Even if a review takes two or more hours, it's necessary. A rushed review can lead to many issues being overlooked which in return hurts the team later, either by leading to errors in a staging environment or even worse in production.
This is also something management usually needs to understand. A review is a part of quality assurance. Cutting time for it hurts the overall quality and maintainability.
Automate The Boring Stuff
Checking for code style or common security issues should be automated. Style issues can be overlooked in reviews too easily and spotting even the most obvious security flaws is sometimes difficult. Automated pipelines can run whenever a review is created. Checkmarks in the review then show reviewers whether basic checks succeeded or failed. They can then concentrate on everything that can't easily be automated and have overall less to do.
Recap
Now that we are through, let's do a recap of the six tips previously presented.
- Make Expectations Clear
- Don't Demand Changes, Make Suggestions And Explain
- Be Open For Discussions
- Eliminate Personal Code Authorship
- Reserve Enough Time
- Automate The Boring Stuff
And now, try to implement some of those tips and you will see how much better your review experience will become!
Before You Leave
If you liked this article, feel free to visit me on Twitter. I regularly post content there in many forms like threads or simple tip tweets.
Top comments (0)