Code reviews are one of those things that you either really love or really hate.
When done well, they can dramatically increase the quality of your code and teach you lots of important practices. Poorly done reviews, on the other hand, can make you dread every time you try to push your code into version control.
While your team's attitude and expertise are the things that have the biggest impact on the quality of reviews, there are some methods for easing the pain. The following are some of the best ways of making the most out of your code reviews.
Limit the number of reviewers to 1 or 2 people
There's a very interesting sociopsychological phenomenon called diffusion of responsibility: a person is less likely to take responsibility for action when others are present. In the context of a code review, it could be roughly translated as the more people receive a request for the same code review, the less likely they are to review the code thoroughly.
It doesn't happen because we are lazy programmers who don't care about code quality. When you know there are other developers inspecting the same code, you feel confident that they will catch the things that slipped under your radar. As a result, instead of getting one or two thorough reviews, you end up with several lousy ones.
The best way to fight this phenomenon is to restrict the number of reviewers: two at most. People take things much more seriously if they know they carry full responsibility for checking the quality of your code.
Get some emotional distance from your code
It's important for us developers to detach from our work.
It's easier said than done: our programs are materialized thought, something deeply intimate. Criticism aimed against our code can feel like an attack to a very personal aspect of ourselves.
We still need to make the effort to handle criticism as an opportunity to improve, not a personal attack. Code reviews have the goal of ensuring our code is in the best possible shape. Integrating that criticism is a great opportunity to improve your craft and learn from other people.
Do yourself and your code a favor and knock it off the pedestal.
Establish what the code review is for
It's useful to set some standard goals for every code review. You should gather your team and discuss which are the most important characteristics the code should meet. Selecting the most important ones and ditching all others is an important exercise with several advantages:
- It helps you focus on the most important aspects of code quality.
- Code reviews tend to be shorter and more focused afterward.
- Agreeing with the rest of the team what to look for in the code helps prevent disagreement later on.
- Is a good moment to refresh knowledge on design principles and code quality.
Another important aspect to discuss is the use of static code analysis tools. There are many ways of enforcing code quality and using a static analysis tool, configured for the team's particular needs, can let the reviewer concentrate on more important aspects of the solution.
When there is agreement on how reviews will be conducted, document it and place it where everyone in the team can see it. There might be disagreements, but having a codified set of rules with is always an advantage. In most cases, referring to the document is enough to de-escalate an argument. If the document needs to be reviewed and changed, it's much better to do it on a base that already exists.
Establish what is out of the scope for the code review
As important as deciding what the code review is for is choosing which things are out of scope. A typical case is delegating some basic stylistic aspects to static analysis tools. Working together, the source control system can leverage such tools to prevent code from being sent to review if it violates any standard.
It's also important for deciding who is responsible for problems if something goes wrong. Once, I had a colleague who got very angry because I didn't spot a bug in his code. The test suit ran and didn't report a problem, and because it was not a bug you could easily find by reading the code, catching it on a review was a bit unrealistic.
Finding bugs should definitely be taken out of the scope of a code review. If you can find one, that's great, but reviewers shouldn't be accountable for not finding every bug in the code.
Provide useful feedback
Feedback should be empathetic and useful. You show empathy by not attacking the author and talking about the code in an objective way. You prove yourself useful by providing advice on how to improve the code or explaining why you think there are better ways of doing things. Code reviews shouldn't be a competition about who finds the most problems in a line of code, it should be about ensuring we are producing the best code we can. Share your knowledge in a constructive way, everyone in the team (and ultimately your end users) will be grateful.
The goal is helping the team
The goal of code reviews is not making your life harder, it's the improvement of code quality. It might seem a bit tiring in the beginning, but once you get used to regular reviews it can even be fun. In the long run, you will enjoy the benefits of working in a better code base and improving your bond with your colleagues. Review often, and review well.
What to do next:
- Share this article with friends and colleagues. Thank you for helping me reach people who might find this information useful.
- Discuss some of these options with your team and assess if it's possible to implement them immediately or if they need tweaks for your specific situation.
- You can find helpful books to continue investing in your carrer in the recommended reading list.
- Send me an email with questions, comments or suggestions (it's in the About Me page). Come on, don't be shy!
