How to perform effective code reviews -- in less time

Create easy-to-review code

Design your code to be easy to review right from the start. This practice will likely reduce the code review duration more than all other recommendations combined. Yet, many development organizations overlook this method.

Here are some ways to design code that's easy to review:

• Establish strict modularization or componentization standards to keep individual units of code below 500 lines -- anything larger is difficult to review.
• Require formatting standards for the code. Also, establish condition-action standards.
• Build your own libraries of useful code components. These libraries provide opportunities to reuse units of code, which only need review once.
• Standardize how developers will comment the code. Require a unit of code to begin with an overall functional description, and that each code block opens with a statement of what's being tested and done.

Next, establish a specific process for code review, and stick to it. The code review process will enforce the rest of your steps. People learn to apply dependable processes fairly quickly. Enterprise clients say formalized code reviews also reduce defects.

A framework meant to reduce review times should test code, structurally validate it using automation and then manually review the code. Generally, it's a waste of time to review code not ready for release. Insert your code review process into the CI/CD or development workflow after testing is complete.

Choose a code review model

Actual code review should start with static code analysis, which tests the code for good development and structural practices. Static analysis helps teams enforce code standards at a high level. The process makes it easier to find deviations to correct so reviewers don't get off track fixing simple formatting issues.

Manual code review should rely on tool assistance where possible. But it's important to first define a review process that fits your organization and development pace, and then pick a tool that can support the procedure. There are three types of code review models. Remember, how you perform code reviews should align with your own natural development practices.

1. Casual inspection. In this model, also called over the shoulder, the reviewer watches the coding process as it happens. While this approach enables faster review and correction, most organizations find casual inspection to be an inefficient use of resources. Paired programming is another form of this model where two developers work together on a unit of code, providing continuous review and feedback. This setup enables developers to make corrections dynamically. When developers can't meet physically, collaborative tools can improve their communication.

2. Collaboration. Here, developers circulate code via email or insert review steps via project management tools. In this peer-review approach, developers collaborate among themselves for review. When the development team is co-located, collaboration tends to occur in real time. Circulation of code via email is a suitable way for distributed developers to collaborate.

3. Tool-managed review. In this process, the organization selects a code review tool, then adapts review practices to how the tool works. This code review approach seems to offer the best results, but only if the organization takes proper care in its tool selection. Several dozen code review tools exist; assess the options and then select a tool that fits your current process with as little disruption as possible.

Slash code review times

Whichever method you choose for how to perform code reviews, several ways exist to make the activity more efficient without reducing the benefits. Follow this advice to see shorter code reviews.

• When developers submit a unit of code for review, require a response within one day. This short turnaround time means developers often assign a review to a group, rather than an individual person. The first available person from that group will take on the code review.
• Don't assign several units of code for review at a time. Wait until review on one unit of code is complete before moving to another; such patience helps each review be focused.
• Optimize the review process in abstract, and then shorten the individual review steps within the procedure. Don't try to speed up the review by changing the entire process; it leads to confusion and lost time.
• Track the time each reviewer spends and compare it to the average. If some reviewers are unusually slow, or if some developers' work needs more review than most, take remedial or training action to reduce the delay.

One more thing: Don't be hasty. Nearly every organization that launches code reviews observes that the time required to complete the process will be greatest when you initiate the policy, but will reduce over time. Some organizations report code reviews in the first two to three months can take as much as 40% longer than they'll take after six months. Don't succumb to the temptation to change things, and don't drop the review policy because of early delays.

If you don't see progress over time, that's when to consider a strategy change. Plan to initiate code review changes well before you need them. Prioritize your steps based on the chances each of the above points will impact your results favorably. Avoid backtracking to earlier strategies, which can demoralize your people. Provide positive feedback when code review strategies succeed -- which they almost surely will.