In Dr. Michaela Greiler’s Code Reviews at Google Are Lightweight and Fast, the author’s team investigated how Google does Code Reviews. And made the relevant summary. The original text with a large number of links, not sorted out here, the relevant links can be viewed in the original text.
Google’s code review has played an important role in engineering practice, and Google has adopted it since its early days. To this day, code reviews are used to make sure the code base is clean, consistent, and that no one is submitting code arbitrarily. Google’s code review process looks similar to Microsoft’s code review process, although there are a few differences that make the code review process light.
This article shows how Google’s code review process works and how it differs from Microsoft’s. In particular, it shows how Google’s 25,000 engineers can conduct code reviews faster than any other company of its size.
Google’s code review study
Google researcher Caitlin Sadowski and others conducted a study to understand Google’s internal code review process. This study is similar to Microsoft’s code review study, so it is possible to compare the code review processes of the two companies.
Google’s common code review process
Google’s generic code review is very similar to Microsoft’s generic code review. Let’s take an example, this time using Mark as a hypothetical employee.
Prepare code for review
It all started when Mark made some changes to the code and wanted to merge those code changes into the shared code base. Like Microsoft, Google has tools for code review. So, before Mark sends his code changes out for review, he uses the tool to look at the code one last time.
Comparison capabilities, provided by Google’s internal code review tool, Critique, make it easy for Mark to find errors and see changes in new versions of code.
Before he can send the code out for review, Mark needs to do one more thing: run the code through a static analysis tool. So Mark ran Tricorder, a tool widely used at Google, and checked the results of the static analysis. When he is satisfied with his changes, he sends them to at least one code reviewer.
Reviewers provide feedback
Code reviewers go through the code and leave comments when they find problems or have questions. Mark then fixes each comment by changing the code or replying to the comment. After Mark makes some changes to the code he examines, he uploads the new version for reviewers to check again. If the reviewer is satisfied, she can approve the change by marking it as “LGTM(Looks Good to me)”. In order to be able to submit code to a shared code base, at least one reviewer needs to approve the code.
This code review lifecycle looks like a copy of Microsoft’s code review. However, I’ll show you some big differences.
Company – wide audit policy
First, Google requires that every code change be reviewed. No exceptions.
At Microsoft, on the other hand, code reviews and how and what they do are determined by the department or team. For example, some teams will skip over minor changes in code reviews. Often, there is no company-wide uniform policy on code reviews. Teams and departments decide how many code reviewers are needed, or how code reviews relate to testing, static analysis activities, and so on.
Google’s code review requires ownership and readability
Also unlike Microsoft, Google has some company-level requirements that code reviewers must meet to approve code changes. This has to do with Google’s strong code ownership. Each directory of the code base is explicitly owned by a group of people. In order to be able to approve code changes, at least one reviewer must be the owner of the code under review. The man acted as goalkeeper. The code can only be checked in if the person agrees.
Another strict requirement is that at least one reviewer must be trained in code “readability.” This means that the person must be certified for readability. This certification shows that they have demonstrated that they know the readability and maintainability of code.
Proof of readability in each language must be obtained. Such standards are a good way to ensure that code specification and design are consistent.
Reviewers are required to be more than just seniority or status
While many other companies (including multiple divisions of Microsoft) value reviewer credentials, areas of expertise, and a hierarchy of decision rights, Google values ownership and readability certifications.
This addresses some common code review pitfalls. Requiring senior developers to approve code can easily lead to overloads and bottlenecks.
On the other hand, it is equally important that enough people have such readability certifications. Otherwise, this will create a bottleneck for auditing. It is well known that waiting for code review feedback is one of the major pitfalls during code review. Although it takes a lot of effort to get a readability certificate, it’s obviously easier than changing levels or qualifications.
How to obtain readability certification
To demonstrate its ability to review code readability, Google’s developers conducted a “review of their code review practices.” Therefore, developers submit code changes to a team of readability experts. These people will check the code. But this review is not like a regular code review. Readability experts scrutinize the code. The purpose of such reviews is to point out each minor error and the potential for improvement, especially in terms of coding conventions and coding styles. Also, nitpicking issues such as indentation or extra space are part of the process. If you are interested, you can find Google’s guide to coding specifications for various languages here.
Once the experts are confident that developers have learned and can apply Google’s coding style and conventions, they issue readability certifications.
What does the approval code require
So, to summarize, to get your code approved on Google, you need at least one code reviewer to own the code and have readability certification in the language used. If these two conditions are met, then we are done.
In addition, there are multiple places on the Google team where developers must approve or enforce different standards on reviewers. However, as a general rule, one developer endorsement is sufficient.
Google’s code reviews are light and quick
Google clearly wants its code review to be light and fast. Even though Google enforces ownership and readability criteria for approval, the code review process is still very fast (4 hours on average). Minor changes will be reviewed within one hour and larger changes within five hours. Other companies reported average turnaround times of more than 15 hours.
So how does Google do this?
Well, looking at the data [2], we can see that there are two important factors: the number of review participants and the size of the change.
Having only one reviewer can speed up code reviews
One of the most interesting findings of the study was that more than 75% of code reviews had only one reviewer. It’s very unusual. Studies have shown that two reviewers provide more valuable feedback.
In Goggle, needing just one reviewer seems like a conscious decision to reduce rigor for the sake of speed. Only in this way can Google achieve fast turnaround times. Bypassing the need to wait for someone else reduces a lot of complexity. But it also undermines the rigor of censorship, which the study notes. How much is lost in quality is unknown. Still, Google seems to be getting good results.
Small steps are critical to quality code reviews
Another key insight from the study was the scale of the modifications. Can you imagine that 90% of code review changes have fewer than 10 files? This is really impressive, and explains why Google reviews code so quickly. Most of the changes also only changed about 24 lines of code. The scale of the change is much smaller than that reported by other companies, including Microsoft.
Reviewing small, consistent changes is a proven code review best practice. First, it improves viewing speed. It also increases the value of code review feedback, as we saw in our study of valuable code review feedback. The effectiveness of code review feedback decreases as the size of code review increases. Google employees know this and often submit small code changes.
Is code review valuable?
In analyzing Microsoft’s code review practices and tools, I often think about what it really means to provide value during code review. When is a code review worth a team’s time?
To answer this question, I turned to developers to ask why they review code and when they derive value from it.
Code reviews have certainly proven to provide value. Even if some code reviews don’t result in any changes, it’s important to note that most code reviews actually have an impact on the code. Otherwise, we can skip them, right?
So, going back to the Google study, I found it interesting that the researchers also assumed that code reviews might be skipped if nothing was done. The good news is that 80% of code reviews in Google do require developers to take action. This clearly shows that code review has a positive impact on the code base. But what about the other 20 percent? A waste of time?
It’s not that simple. Fortunately, code reviews have a wide range of benefits.
Google’s motivation and benefits for code review
Although code reviews are often associated with finding bugs, some research on code reviews suggests that the benefits and incentives for doing code reviews go far beyond that. In addition, Google employees know the benefits of code review in many ways, especially following code review best practices. The original vision of the staff who introduced code review at Google was to force developers to write code that other developers could understand.
In this study, Google employees explained the following motivations for code reviews:
• Education (mentoring, learning, knowledge dissemination)
• Maintain specifications (e.g. proper testing, consistency of style and design)
• Daemon (ensures security and provides an additional safety net so that a single developer cannot commit arbitrary code)
• Accident prevention (including ensuring that errors and defects are prevented as well as possible, and that source code quality is high).
• Trace and trace decisions (understand how code evolves and why and how it changes)
Motivations vary from role to role
Another interesting finding of code review research at Google is that the motivation and expectations for code review depend on the roles and responsibilities of the stakeholders. For example, managers are more interested in the benefits of creating consistent coding styles in a code base. Developers, on the other hand, are more concerned with finding defects or bugs.
Google employees and Microsoft engineers have the same reasons for code review, except that Microsoft employees do not describe code review as a “guardian” approach. For example, security checks are not part of Microsoft’s regular code review process.
Google’s code review tool
At Google, code review can be done with tools. Google uses two main code review systems. For open source code and code shared with external collaborators such as Go, Chromium, and Android, Google employees use the Gerrit code review tool. Gerrit is an open source review tool integrated with Git.
For internal code, on the other hand, Google employees use an internal code review tool called Critique. There is no detailed description of Critique, but Google employees seem very comfortable with the process and functionality.
Many of Microsoft’s code reviews are also performed through tools. But at Microsoft, other forms of code review are guaranteed to be fair and reasonable. Sometimes, nothing beats face-to-face conversation.
Google’s unified process is optimized for speed
To sum up, Google has a clear policy on code review. Your relationship with the submission of a shared code base is at least one review approval with code ownership and readability certification. Most reviews have only one reviewer, which also lightens the code review process. Company-wide code specification to make code clear and easy to read. Combined with small code changes, Google employees can get code review feedback in 1-5 hours.
Similar to Microsoft employees, Google employees are very satisfied with the code review process and find it a valuable engineering practice.
reference
[1]https://github.com/google/styleguide
[2]https://sback.it/publications/icse2018seip.pdf