Code reviews are a largely accepted best practice for software development teams. There are a lot of benefits to using them and there is always something to learn as a reviewer. But adopting from zero code reviews isn’t so easy and immediate.
It’s important to share why they are so important for a team and what are their goals:
Quality control: code reviews can increase the quality because we can find new solutions and improvements
Sharing knowledge: It’s easy to end up in a situation where one developer deals with a certain part of the codebase because they’re most familiar with it. in short-period seems a win but it’s not for the future. When ownership is shared, teams become more motivated and autonomous.
Increasing developer's knowledge: we can learn through code reviews, by asking questions about a piece of code that we don’t understand, or by sharing a different method to solve the problem
So after sharing why code reviews are so important it’s time to understand what are some tips and tricks for using them correctly and take advantage of them.
1 Keep Pull requests small
Keeping the Pull requests smaller as possible allows for the easiest review and, usually, more contribution and focus on it.
If you create a bug pull request with 120 files changed, 12000 lines added and 3500 lines removed it’s very difficult to find problems or better solutions. It’s totally a waste of time reviewing such a big pull request and it takes too many hours for doing it.
For that reason, it’s better to split the pull request into different pull requests with a specific code review.
A SmartBear study of a Cisco Systems programming team revealed that developers should review no more than 200 to 400 lines of code (LOC) at a time because the brain can only effectively process so much information at a time; beyond 400 LOC, the ability to find bugs, defects diminishes.
In practice, a review of 200–400 LOC over 60 to 90 minutes should yield 70–90% defect discovery. So, if 10 defects existed in the code, a properly conducted review would find between 7 and 9 of them.
2 Don’t review for more than 1 hour
Usually, it’s not a best practice to review code too quickly, on the other side you shouldn’t review for too long because performance starts to decrease after about 1 hour.
Our brain needs a break to refresh to have good performance and to review well the code.
It’s important to keep the focus on the review to discover and understand every single part of the pull request.
Doing a superficial review it’s not a good practice and decreases the credibility of the process for the whole team.
3 Add a clear description
To help reviewers to do their job it’s important to add a description to the pull request to share:
which problem are you trying to solve
why did you choose that solution
doubts about something
question about the implementation
…
It’s also important to add a clear description for the future, for example, after some months you would like to understand why that piece of code was added. There are a lot of benefits to adding a clear description!
4 Use Pull Request template
Many tools, like GitHub, provide a template to create Pull Requests, in this way you have a standard and it’s easier to create a new one and review it. If you want to add the template.
GitHub you need to create a new file .github/pull_request_template.md
Github Documentation: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository
Using a template allows the team to create a standard pull request to help each member of the team.
5 Number of reviewers
What is the correct number of accepted reviews to merge a pull request? There isn’t a specific rule again but it’s important to decide it in the team and try to understand what is the correct number.
Usually, you don’t need that every member of the team accepts the pull request, except for some critical features.
Sometimes one or two accepted reviews are good enough to merge the pull request.
Why not everyone?
Because you can create a bottleneck and your deployment can be blocked by some reviewer that didn’t see it already for other reasons.
6 Empathy
Empathy is an important skill during the review.
As a reviewer, you need to understand what the author is trying to solve, what was his thought, and why it’s implemented in this way.
You need to be kind when you comment on the pull request without being rude.
Don’t try to give a new solution, instead ask questions about the implementation like: “Is this the only way to solve the problem?” “It seems a little bit coupled with this code, what do you think? Is there a better way?”
If you liked a piece of code or you learn a new thing write a comment like: “this is perfect, I never thought about it” or “I didn’t know about this function! Amazing, it seems very useful!”
Try to foster a positive code review culture!
7 Delegate static analysis
Using a tool to automate static analysis checks it’s important because during reviews you need to focus on behaviors, business logic, and patterns you don’t have to focus on spaces, missing commas, or things that the static analysis tool can check.
All the automatable static analysis checks should be delegated to these tools during a CD/CI process.
This delegation can save you a lot of time and allows the team to focus on the business logic and the high-level approach to the implementation.
8 Run a retrospective
After a month or two of reviews it’s important to understand if the process is good or not and how can you improve it.
To do it I can suggest running a retrospective to understand it.
It’s important to find an external facilitator so all the team can discuss together what was good and what was not.
There is a lot of different type of retrospectives and the facilitator can use one of them.
Every month or two it’s important to run the retrospective, especially in the early stage of the adoption process, to improve it and create a feedback process for all the team.
Conclusion
Code reviews are a fantastic tool but you need to know how to manage them to get all the benefits.
There is always something to learn and improve in this process to discover with your team and discuss it.
I enjoy creating pull requests and reviewing the code of others, I always learn something and understand other points of view.
Never stop learning.
Oldest comments (0)