Estimated reading time: 10 min
Code review is one of the most essential practices in software engineering, used to improve the overall quality of code. However, teams that adopt this practice often forget it offers many other benefits aside of improving software. Check out my latest article about reviewing code that I originally wrote for the Faye Business Systems Group company blog and learn how to deliver a positive impact on both people and code.
What Is Code Review?
Code review is a process involved with software engineering, which is mainly aimed at improving the quality of the code that is subject to review. Usually, this practice consists of one or more people (i.e., “the reviewers”) examining a piece of code after (part of) the implementation is finished. At least one of these reviewers must not be an author of the evaluated code. In general, this process could be described as people giving feedback about code to other people.
Quite often, teams give up on some of the immense benefits that such reviews can offer. Instead, they focus too much on the code and miss out on the people. In this article, I’d like to share some of the great tips I’ve learned over the years about delivering a positive impact—on both people and code.
Code review is not exclusively about bugs.
As mentioned, improving the quality of code over time is among the main objectives of a systematic code review. The single most important aspect is finding problems (i.e., defects).
Popular categories of defects include:
- Non-compliance with the business requirements (i.e., specification)
- Improper code design
- Performance issues
- Security vulnerabilities
When a defect gets verified and accepted by the development team, it becomes a bug. But at times, these two terms are used interchangeably. Aside from eliminating problems, better code quality can mean improved readability (i.e., code style) and maintainability.
Often, the review sparks a discussion, which results in finding new, better implementation approaches. This occurrence brings us back to the people. The conversation between an author and a reviewer is an extremely powerful tool that impacts both parties, as well as the code itself.
First off, it’s a fantastic tool for knowledge proliferation. Developers can exchange their experiences, learn about best practices, or discuss alternative solutions—just to demonstrate a rare use case that would otherwise go unnoticed. This discussion can also encompass managing expectations about quality and the process itself.
One of the key aspects of code review that involves people is cultivating a team spirit. Getting involved in the process propagates awareness of mutual responsibility for the delivered software. It also reiterates the fact that the code belongs to all developers involved in creating and improving it.
Being detailed is great, but the big picture is what really counts.
Keeping the different benefits of performing a code review in mind should always happen in the context of the project and the specific team. Most often, the main objective will involve catching bugs before they get integrated into the production code.
But sometimes, the primary goal is to examine the codebase against performance issues or security concerns. In this case, pointing out other (i.e., lesser) problems isn’t critical. The focus of a particular code-review session will always depend on the agreed-upon objectives, the specific rules adopted by the team, and the available timeframe.
Usually, the time for the review is limited, and it might be very difficult to check everything in detail. So it’s imperative to determine the most important priorities, especially if the general purpose of code reviews isn’t well-defined by the organization.
If your team needs to focus on prioritization, the review should first find out if the code does what it’s supposed to do (i.e., meets the requirements) without making any apparent errors or having security-related issues. Then if time allows, focus on other things, such as overall design, minor bugs, performance, code style, and implementation alternatives.
It is crucial to adopt a positive mindset.
Probably one of the most important pieces of advice for reviewers (and managers) is that the code is not the same as the person who wrote it. In other words, the code should be under critique, not the people behind it.
When your work is constantly examined by others, it can be stressful in and of itself. But when the number of found defects is used to evaluate team members (e.g., performance reports), the situation quickly becomes toxic. Don’t let this scenario happen, as it will turn the developers against the process. Then they’ll start optimizing for metrics, rather than good code.
It’s essential to foster a culture of collaboration and learning. Each problem is an opportunity for the author to learn something new and for the whole team to improve the overall quality of their work. Knowledge should proliferate in all directions. Then even the most experienced engineers can benefit from it. In general, a properly conducted review allows both the reviewers and authors to become better and grow.
It’s always important to try to understand the author’s perspective. So you should stay humble and remember there are usually many correct ways to solve any given problem.
The language you use can make or break your project.
The language used in code reviews has a tremendous influence on the atmosphere of the team. If your comments are harsh and critical, the situation can quickly get tense, and the work environment can turn into a warzone. But if you give constructive feedback in a positive and empathetic tone, you will foster collaboration and help the authors write better code next time.
Remember, give credit where credit is due. All human beings need to be acknowledged, especially engineers who are (usually) passionate about what they do.
It’s also important to adopt a precise method of communication you can adjust to the severity of found issues. Consider using the words “might,” “should,” and “must” in different situations. Then you can indicate an alternative approach (i.e., a soft remark) , a suggestion (i.e., something the author might adopt), or a requirement the author is obligated to follow (i.e., a blocking comment ). Here are a few more hints about communicating in a way that allows your team to get the most out of the review process:
- Be detailed and explicit in your comments. Clearly describe your intentions.
- Ask questions, instead of making statements. But avoid using the word “why.”
- Assume authors are smart and want what’s best for the project.
- Ask for clarification, rather than correction.
- Support collective ownership of the codebase. Avoid using “mine,” “yours,” etc.
- Don’t be sarcastic, and don’t make jokes. Be humble.
Closing Word
This article depicts various advantages that can come from the process of reviewing code. If performed correctly, it can lead to improved code and numerous benefits for both the individual engineers and the whole team. As a result, your projects will run smoother, and your developers will be more satisfied.
We’ve learned that code review is a two-way street, and we’ve covered some of its lesser-known purposes, as well as common pitfalls any team should avoid. It might not be easy to simultaneously adopt all the best practices, see beyond the code, and think about its impact on people. But in the long run, it’s definitely worth it. At the end of the day, any team is only as strong as its weakest reviewer.
If you liked this post be sure to checkout my other articles here.