Code Review Practices to boost your productivity: Lessons from Microsoft

Code review best practices are crucial for teams that implement code reviewing. Even though code reviewing is a widely adopted and adapted software practice and provides many benefits, it is also time-consuming and comes with several challenges teams have to overcome.

This blog post gives a small summary of the keynote I gave at QUATIC. QUATIC is the 10th international conference on quality of information and communication technologies.

I have researched code reviewing practices extensively over the last years. At Microsoft, we have a close eye on the code reviewing practices of the engineering teams across the company. We regularly perform studies to evaluate how well this practice works for different teams.

Below a few of the key findings from our studies that generalize across teams and organizations. If you really want to deep dive into code reviews check out what I wrote about code review pitfalls, code review best practices and how code reviews work at Microsoft.

Code review best practice 1: Require approval before checkin.

Microsoft is a large organization. Still, most of the engineers (>90%) who perform code reviewing use one internal tool called CodeFlow. The code review best practices and policies on the other hand differ slightly. Still, for almost all teams an approved code review — next to successful test and analysis runs — is a prerequisite for a code change to be permitted to be checked into the shared code base.

Code review best practice 2: Small, incremental changes.

The larger the change under review, the less useful the feedback of the code reviewers Click To Tweet

The larger the change size under review (counted by number of files changed), the less useful the feedback of the code reviewers. The reason for this is fairly obvious. Engineers just have a hard time to understand the code change if the change is large and comprises several entangled changes. This limits their ability to contribute valuable feedback. Large code changes also increase the time reviewers need to perform the review, which often results in less diligently reviewed code.

Code review best practice 3: Choose code reviewer with experience.

A code reviewer that has either reviewed or changed the code under review before gives more valuable feedback. Click To Tweet

A code reviewer that has either reviewed or changed the code under review before gives more valuable feedback. The main difference comes from a single review, or a single change. For example, a reviewer who has reviewed the code once before gives already 30% more useful comments, than a reviewer who sees the code for the first time. Also, the experience a reviewer has in the organisation influences how useful the code review comments will be. We could see that especially during the first year, the feedback usefulness increases with time.

Code review best practice 4: A heads-up increases review speed.

As one engineer puts it:

Usually you write up some code and then you send it out for review, and then about a day later you ping them to remind them… and then about half a day later you go to their office and knock on their door.

To conquer this challenge, code change authors should aim for small, incremental changes. Also, many engineers give their reviewers a heads-up that a review is coming in order for them to schedule some time for the code review. Also, giving reviewers a quick walk through so that they are able to quickly give meaningful feedback can be helpful.

Checkout the slides for more challenges and best practices.

Does your team implement some of the code review best practices? What’s your secret to make code reviewing work? What is the main pain point during code reviewing?

To deep dive into code reviews, check-out my large code review blog post series.

Code review best practices: Lessons from Microsoft. Checkout blog post & slides http://goo.gl/c7q0E0 Click To Tweet

On to code review lessons learned at microsoft from Michaela Greiler

Updated on July 10th, 2019