When creating a list of reasons to consider being a developer, don’t forget about the code review process, a critical stage that’s also often an incredible cause of delay and frustration to developers and their teams. Even if you’re learning some coding for your own business or an understanding, such as creating your website, for say, marketing your plumbing business.
The fact that code review is a complex process is hardly surprising, given that it often requires communication, context-switching, collaboration as well as subject matter expertise. At a point in time where releasing secure codes as quickly as possible has never been more urgent, it’s not a stretch for code reviews to feel like a challenge to some teams, especially if the process is not properly integrated into an existing workflow.
Still, code reviews at Google are widely adopted and play an important role in keeping the codebase coherent and clean and ensuring no arbitrary code is released. Google offers some specifics that allow for a lightweight code review process.
Here is what the code review process at Google looks like
What is it?
A code review, also known as Quality Assurance, is the process of having others examine your code after writing it.
While code reviews are often associated with discovering bugs, there are several other motivations and benefits for doing code reviews. Also, Googlers understand that the benefits of code reviews to writing and releasing software are plenty, especially if best practices are followed during the practice. These include:
- Ensures you have a consistent codebase.
- It teaches all review members (knowledge dissemination or transfer).
- Creates contextual awareness about what might affect other aspects of the team
- Helps with gatekeeping and ensuring security is maintained so that a developer doesn’t commit arbitrary code.
- Prevents breaking builds
- It helps avoid accidents, including ensuring defects and bugs are prevented, and the source code is of good quality.
- Examines code change to look for simplifications and optimizations in the change.
- It helps with tracing and tracking decisions to understand the evolution of the code and how and why changes happened.
Google possesses 1,918 repositories across various languages on their GitHub, and even more that are not open source.
A single codebase is shared by more than 25,000 Googlers and typically achieves 40,000 commits daily (24,000 changes by automated systems and 16,000 human changes). Each day it serves about 800,000 questions per second during peak hours.
How does Google review code at their scale with so many daily commits?
How to Prepare for Google Code Reviews
Before considering the code review process, you first focus on who will perform the review. You need to choose a subject matter expert. Select someone familiar with the particular codebase or the general area of the codebase.
This may sometimes mean having different individuals review various parts of the code. However, less than 25% of Google’s code reviews have more than a single reviewer.
Getting a reviewer to deliver a timely response is also crucial. To avoid challenges such as overloading individuals, it’s best to use a code review template and CC reviewers to the change allowing them to review at their convenience.
Why It’s Crucial to Run Fast Reviews
Generally, code reviews should be done quickly. The standard maximum time length for a review should be one business day.
But why is this important?
It develops into a blocker. While the code owner can proceed to do other work, new codebase changes easily form a backlog, and the delays sometimes build up to days or weeks.
Causes frustrations. If the reviewer requests major changes to the codebase but only responds after days, it becomes frustrating for the developer working on the change.
The quality of the code can degrade. Slow reviews reduce the chances of developers working on code clean-ups or general code improvement. This makes it possible for code quality to go down.
The primary reason code reviews can and should be fast is that they are small. Instead of sending a 1,000 line change list (CL), they are divided into various CLs, for example, sending 10 smaller changes of 100 lines.
There are also some Google emergencies where changes to the codebase have to be quick to resolve major production issues. In these cases, the quality of the code is relaxed. The review immediately becomes the individual’s priority.
Code Review Standards at Google
Google emphasizes a key rule for code reviews: Reviewers should approve a code change once its overall health definitely improves, even if it’s not perfect.
The point Google seeks to make is that there’s no perfect code. If it makes things better, then that’s enough.
This creates a balance between something better and how much better it could get. If a reviewer adds more feedback leading to significant improvements, there may be a need for more work on the code.
What do Google Reviewers Examine in Code Reviews?
During code reviews, the following elements become the center of attention according to Google’s documentation on engineering practices:
Design: Is the codebase appropriate and well-designed for your system? Does the change belong in your codebase? Does the codebase integrate well with other parts of your system?
Functionality: Is the code behaving like the author possibly intended? Is the code’s behavior good for users?
Complexity: Is it possible to make the code simpler? Would it be easy for a different developer to understand and use the code if they later come across it? Is the code over-engineered for its existing use cases?
Tests: Are there correct and well-developed automated tests for the code? Will the tests fail when the code is broken? Will the tests generate false positives? Do the tests deliver simple and valuable assertions?
Naming: Does the developer have clear names for classes, variables, methods, etc.?
Comments: These should be clear and useful where sensible comments explain why it’s done rather than how.
Style and Consistency: Is the code aligned with our style guides?
Documentation: Is there relevant documentation updated by the developer?
Google uses style guides across multiple languages, including JavaScript, C++, HTML/CSS, Lisp, Swift, and more.
Creating a document that’s easily accessible to everyone helps standardize the code. Plus, it helps clarify the expectations in the code review process.
How Do Googlers Review Code?
Google code review is often a three-stage process according to their engineering practices. Here is a list of the stages you need to consider:
1. Get a comprehensive overview of the code change
Examine the description or summary of the code changes. Does it make sense? For instance, if an individual change a codebase to be deleted the following week, courteously reject the change and explain why it might no longer be needed.
It’s inefficient for people to spend time working on things that aren’t actually needed, so look at the life cycle of your development process and examine why it’s happening. The earlier you solve this, the better.
To get a comprehensive overview of the code, you may need to briefly scan the components of the code to see how it all works together and to share any observations or serious architectural issues.
2. Review the primary parts of the code change
After the overview, examine the main parts of the code change. The CL’s file with the highest number of changes is the main piece of the CL that needs reviewing. This develops context to the smaller pieces and makes the review faster. Too larger CLs should be split into smaller changes.
3. Examine the rest of the code sensibly
Once you complete the overview of the change, focus on the details and proceed with a single file at a time. You can choose to follow the order presented by the control or pick a particular one. Regardless, it’s crucial to review everything missing nothing.
Summary
Generally, a code review works best when the developer is paired with reviewers capable of delivering quick responses to a review within a reasonable time. And the best reviewer is someone who gives the most correct and thorough review for the piece of code written by the author.
Last Updated on by kalidaspandian
