In 1988, Hewlett Packard (HP) conducted an internal review of their software development processes and set a target to improve their code quality tenfold. To meet this ambitious goal, they tried a number of approaches. Eventually, they concluded that incorporating code reviews into the development cycle saved more money than resolving defects after they were found by customers.
fyi
A code review (also referred to as peer code review) is a process where one or two developers analyze a teammate’s code, identifying bugs, logic errors, and overlooked edge cases.
Granted, when HP made this realization, software development practices weren’t as well defined and mature as they are today. But organizations have long recognized that making code review a part of their software development lifecycle could result in positive outcomes.
More than three decades later, the software development industry is still exploring the benefits of code reviews. According to Smartbear’s survey from 2020, respondents voted code review as the number one way to enhance code quality.
Here are five code review best practices to maximize the value of a fresh perspective by identifying poor design patterns and bugs, ensuring that every new feature or product is created using high-quality code.
1. Create a code review checklist
A code review checklist is a predetermined set of questions and rules your team will follow during the code review process, giving you the benefit of a structured approach to necessary quality checks before you approve code into the codebase. Your checklist may include:
- Readability: Are there any redundant comments in the code?
- Security: Does the code expose the system to a cyber attack?
- Test coverage: Is there a need to test more cases?
- Architecture: Does the code use encapsulation and modularization to achieve separation of concerns?
- Reusability: Does the code use reusable components, functions, and services?
2. Introduce code review metrics
You can’t correct someone’s code quality without measuring it. Objective metrics help determine the efficiency of your reviews, analyze the impact of change on the process, and predict the number of hours required to complete a project.
Some commonly used review metrics include:
- Inspection rate: The speed at which your team reviews a specific amount of code, calculated by dividing lines of code (LoC) by number of inspection hours. If it takes a long time to review the code, there may be readability issues that need to be addressed.
- Defect rate: The frequency with which you identify a defect, calculated by dividing the defect count by hours spent on inspection. This metric helps determine the effectiveness of your testing procedures; for example, if your developers are slow to find defects, you may need better testing tools.
- Defect density: The number of defects you identify in a specific amount of code, calculated by dividing the defect count by thousands of lines of code (kLOC). Defect density helps identify which components are more prone to defects than others, allowing you to allocate more resources toward the vulnerable components. For example, if one of your web applications has significantly more defects than others in the same project, you may need to assign more experienced developers to work on it.
3. Ensure your feedback justifies your stance
When reviewing code, don’t simply suggest what needs to be fixed or improved upon – explain why the developer should make that change.
During development, you’ll mostly deal with problems that can be solved with multiple solutions. The comments you include in the code are a product of your knowledge and experience; you might prefer tackling an issue in a specific way, which may be different from the code author’s approach. Therefore, you should articulate your coding choices to explain your reasoning.
For instance, suppose you review a piece of code where you don’t think multi-threading is required. Instead of simply advising the developer against using threads, explain that the concurrency model isn’t offering any performance advantage in their scenario and therefore they should make their code single-threaded.
There are two benefits to this approach. First, the code’s author will know why they should make a particular change, which will help them tackle similar problems in the future. Second, since you already justified your comments, they won’t need to follow up with you about the reasoning behind your comment, saving both of you time.
4. Don’t review more than 200-400 lines of code at a time
Reviewing more than 400 lines of code (LoC) can have an adverse impact on your ability to find bugs, and in fact, most are found in the first 200 lines. This limitation affected industry practices after Cisco identified it in a comprehensive study on code review.
The study found that, once developers reviewed more than 200 lines, their ability to identify defects waned (see the chart below).
5. Supplement your best practices with automation
If you use Bitbucket as your git solution, enhance your source code management (SCM) workflow with an app like Workzone, which can help you plan how and when to push changes and how to add reviewers and groups to new pull requests. You can also set predefined groups and reviewers to pull request source and branches, so newer pull requests include them by default. This way, organizations can implement their SCM process in a simple and user-friendly way.
Another Bitbucket app that can help you to automate your code reviews is Code Owners for Bitbucket. This tool lets you decide which users in Bitbucket should review pull requests using a concept known as code owners. Code owners are individuals who have knowledge and experience in a particular coding niche (e.g., developing applications in Spring Boot). Use code owners to ensure that the right developers have reviewed the code as merge checks.
To find more code review apps, browse the Atlassian Marketplace.
psa: code review is an opportunity for growth, not criticism
While building a code review culture, make sure your developers aren’t intimidated by the process. Avoid evaluating the performance of your developers by reviewing the defects identified during their code reviews. If this becomes a benchmark for promotion or compensation, your developers are likely to feel threatened by the process and hostile to it.
Instead, use code reviews as an opportunity to empower junior developers to learn from their senior counterparts. You’ll spot bugs earlier, when they’re cheaper to fix, improve coding standards compliance, and enhance the overall quality of your code. Approaching code reviews in this way creates an opportunity for your whole team to level up together, resulting in smoother, more efficient work on future projects.