While code review is a widely adopted practice, there are so many ways to accomplish it that it's become fairly common for teams to struggle with the best way to do it. I will venture to say that this is one of those areas where you need to be somewhat flexible. How you implement a code review process can depend on:
How many developers do you have on staff with enough expertise and diplomacy to be your reviewers? I’ve spoken with people who voiced concern that they only have one senior developer on their team and if they use them to review code, they won’t get the benefit of having them be hands-on coders. I get that – I’ve been there. In a small team, depth is always a problem, no matter what you are trying to accomplish.
Where is your team located? Are they spread across geographies or sitting together in an open room? Reviewing code requires concentration and feedback, both of which are easier to provide when the developers are sitting next to each other. Processes like “over the shoulder” code reviews are difficult to implement if your team isn’t co-located.
What kind of rules and regulations govern your industry? If you are in a regulated industry, you may have to adhere to rules about auditing and reporting, which means you must have some way to track the frequency and quality of your code reviews. If you are in an industry in which security is a major factor, you may also be required to focus on security vulnerabilities during code reviews.
How complex is your code? Will one reviewer suffice or do you need to have multiple reviewers with different expertise? For example, game development can involve some very sophisticated logic to handle character interactions and scenario tracking, while at the same time incorporating specific animation and memory management techniques. Having multiple “sets of eyes” on that code may be the most productive way to review complex code like this.
And in many cases, you will have different needs for different projects – you may have multiple teams building applications that don’t have the same profile or needs. Having a code review tool you trust can help you implement a solid code review process no matter which method you decide to use in your organization. Here are few tips for incorporating a tool into your code review process and solving some of the issues you might be facing:
1. Facilitate conversation
Any kind of review process, whether it’s code or documentation or performance, is always best done face to face. After you’ve reviewed the code using the tool, schedule time with the developer to provide verbal feedback. If you aren’t co-located, you can do this over video or phone but it’s important to have a conversation about the feedback so you can use the code review as a means for collaboration and mentoring.
2. Use your experts
If the code under review has touch-points with other areas of code or have implications for security, performance, extensibility, etc., you may not be able to tap just one person to provide input. You may need to have multiple people look over the code to ensure that all of the ramifications have been considered. In this case, it’s good to have a review pool that includes multiple people with different expertise. A tool will allow you to identify the people who should be in that pool and route the code to them as needed. You can also use the tool to capture their comments and make those comments visible to the whole review team so everyone can learn from each other.
3. Make the review comments public
One of the benefits of a tool is having multiple people review the same code in a concentrated manner. Pulling together a group of people into a room to do a team review makes it difficult for each person to mull over the potential "gotchas" with the code from their own perspective. However, you can use a tool to queue up the code for each person while still allowing the team to see each other’s comments. Being able to see both the code and the other reviews has multiple benefits:
- No duplicate comments – if someone else said it first, you don’t have to pile on.
- Team learning – again, being able to see someone else’s input allows the reviewers to learn from each other as well as the developer whose code is being reviewed.
- Review of the review – yes, it gets a little Escher-like. But sometimes one reviewer can catch an issue with another reviewer’s input, which can head off issues being introduced into the code as a result of the review
4. Learn from the metrics
One thing you definitely can’t get from code review that doesn’t use a tool is metrics. Using the metrics as a means to improve your code base is a very powerful addition to your code review process. A tool will tell you what the most common mistakes are and where they are being introduced or repeated. You can also discover which areas of your code seem most vulnerable to quality issues based on the number of defects logged during the review cycle. Preventing bugs from being checked in is obviously the most economical and efficient way to ensure quality code – using the metrics to determine where your developers need training or coding standards can help to guide them in delivering better code.
5. Find your future code reviewers
This tip isn’t really specific to a tool, although a tool gives you a clear picture (through the metrics) of which developers deliver the highest quality code. But you do have to build your depth and that means making it a distinct effort to identify those members of your team who can move into this role. Ideally, you would have an entire team of developers who were capable of performing peer reviews – this is the most collaborative and efficient way to deliver great code on time. But it takes focus and effort to build that level of expertise across the team.
However you decide to implement code review, it’s important to use it as a constructive and collaborative way to build great products. The whole point of code review is to increase the quality of your code and the best way to do that is to inject it into your organization in a way that encourages learning and teamwork.