So let me show you how code reviews at Google look like and what sets them apart from code reviews at Microsoft. In particular, I’ll show you what allows the 25,000 engineers at Google to review their code much faster than at other companies of this size. So, let’s get started.
Code Review Study at Google
A typical code review process at Google
Preparing code for review
It all starts after Mark has made some changes to the code and wants those code changes to be merged with the shared code base. At Google, code reviews are, similar to Microsoft, done with the help of a tool. So before Mark sends his code changes out for review, he uses the tool to look through the code one last time.
Critique, Google’s internal code review tool, offers some diffing capabilities that make it easy for Mark to spot errors and see what has changed in this new version of the code.
Reviewers give feedback
The code reviewer carefully looks through the code and leaves comments if she sees a problem or needs some clarification. Mark then addresses each comment either by changing the code or replying to the comment. If Mark made some changes to the code under review, he uploads the new version for reviewers to check again. If a reviewer is satisfied, she can approve the change by marking it as “LGTM” (looks good to me). To be able to commit the code to the shared code base, at least one reviewer must approve the code.
Looking at this code review lifecycle from a distance it looks like a carbon copy of a code review at Microsoft. But, there are profound differences that I’ll show you now.
Company-wide policies for Approval
First of all, Google requires each code change to be reviewed. No exceptions. Period.
At Google, each code change is reviewed. Period. (CLICK TO TWEET)
Code reviews at Google address ownership and readability
Also contrary to Microsoft, Google has some company-wide requirements that must be fulfilled by the code reviewers in order to be able to approve the code change. One has to do with Google’s strong code ownership. Each directory of the code base is explicitly owned by a set of people. To be able to get the code change approved, at least one reviewer must be an owner of the code under review. That person acts as a gatekeeper. Only if this person gives his or her okay, code can be checked in.
Another strict requirement is that at least one person on the review must be trained in code “readability”. What this means is that this person must have obtained a readability certification. This certification shows they’ve demonstrated they know how readable and maintainable code looks.
The readability certification must be obtained per language. Having such criteria is a great practice to ensure consistency in style and design.
To get decision power, reviewers at Google must obtain a readability certificate that shows they understand what readable code looks like. (CLICK TO TWEET)
Requirements for reviewers aren’t focused on seniority or status
So, while many other companies, including several divisions at Microsoft, rather look at the seniority of the reviewer, the area of expertise or the hierarchy to grant decision power, Google looks at ownership and readability certification.
How to get a readability certification
Once the experts are convinced that the developer learned and is able to apply Google’s coding style and conventions, they issue the readability certification.
What it takes to get code approved
So to recap, to get your code approved at Google, you need at least one person on the code review that has ownership over the code and the right readability certification for the used language. If those two criteria are met, you are good to go.
No rule without exceptions. Also at Google teams exist where more than one developer must approve or where different criteria for reviewers are enforced. But, the general rule is one developer’s approval is enough.
Code reviews at Google are light-weight and fast
Google explicitly wants its code review practices to be light-weight and fast. And even though Google enforces the ownership and readability criteria for approval, the code review process is – with 4 hours on average – really fast. Small changes are reviewed within 1 hour, larger ones within 5 hours. Other companies report average turnaround times of over 15 hours.
At Google, code review are on average completed within 4 hours. (CLICK TO TWEET)
So, how does Google do it?
Requiring only one reviewer speeds up code review times
One of the most interesting findings from the study is that more than 75% of the code reviews have just one reviewer. That’s unusual. Especially because studies have shown that two reviewers tend to give more valuable feedback.
Requiring only one reviewer seems like a conscious decision at Goggle and trades review rigor for speed. Only that way, Google can realize fast turn-around times. Skipping the need to wait for another person reduces a lot of complexity. But it hurts review rigor, as also the study mentions. How much this costs in terms of quality is unknown. Still, Google seems to have great outcomes with this set-up.
Small change sizes are essential for fast and high-quality code reviews
Another crucial insight from this study is the size of the change. Can you imagine, 90% of the code reviews have fewer than 10 files changed? That’s truly impressive and also explains why code reviews at Google are lightning-fast. Most of the changes also have only around 24 lines of code changed. That’s a much smaller change size than reported by studies of other companies, including Microsoft.
Code Reviews at Google are fast for two main reasons. First, 90% of code reviews at Google comprise less than 10 files. Second, 75% of the reviews have only one reviewer. (CLICK TO TWEET)
Are code reviews worth it?
While analyzing code review practices and tools at Microsoft, I often thought about what it actually means to provide value during code reviews. When are code reviews worth the time a team spends on them?
To answer that question, I turned to the developers and ask them why they are doing code reviews and when they get value out of them.
Code reviews must lead to change to unfold their true value. (CLICK TO TWEET)
So, coming back to the Google study, I found it interesting that the researchers also had the premise that if there is no action taken, the code review could have been skipped. The good news is 80% of the code reviews at Google do require the developer to take action. This clearly shows that code reviews have an active impact on the code base. But what about the 20%? Is that time wasted?
Well, things are not that simple. Fortunately, code reviews provide a broad set of benefits.
Motivations and benefits for code reviews at Google
In the study, Googlers report the following motivations for doing code reviews:
- Education (mentoring, learning for developers, knowledge dissemination)
- Maintaining norms (such as having adequate tests, consistency in style and design)
- Gatekeeping (ensuring security, and having an additional safety net so that a single developer can not commit arbitrary code) and
- Accident prevention (this includes making sure bugs and defects are prevented as good as possible, and that the source code is of high quality).
- Tracing and tracking decisions (understanding the evolution of the code and why and how changes have happened)
Motivations change per role
Another interesting finding from the code review study at Google was that the motivations and expectations for doing code reviews depend on the person’s role and responsibilities. A manager, for example, is more interested in the benefit of creating a coherent coding style at the codebase than a single developer. On the other hand, developers are more concerned with finding defects or bugs.
The reasons for code reviews reported by Googlers are aligned with the reasons reported by Microsoft engineers, except that Microsofties do not describe code reviews as a way of “gatekeeping”. Security checks, for example, aren’t part of the normal code review process at Microsoft.
Google’s code review tooling
A lot of code reviews at Microsoft are also performed via tooling. But at Microsoft, other forms of code reviews, such as over the shoulder reviews, have their fair and justified warrant. Sometimes, nothing can beat a face-to-face conversation.
Google’s uniformed process is optimized for speed
To sum it up, Google has clear guidelines on what it takes to get a code review approved. What stands between you and the commit to the shared codebase is a review approval from at least one person with code ownership and readability certification. That most reviews only have one reviewer takes also a lot of complexity out of the code review process. Company-wide code styles, make it crystal clear how readable code must look like. This combined with the small code change sizes allows Googlers to expect code review feedback in 1-5 hours.
Similar to Microsofties, Googlers are very satisfied with the code review process and find it a valuable engineering practices.