Software Engineering At Google
Chapter #9 - Code Review (1 of 3)
Software Engineering at Google Chapter #9 - Code Review (1 of 3)
The code review process varies wildly from company to company
Generally, code reviews are a combination of process and tool(s)
Review code before it’s committed
Google’s code review workflow:
Author makes a change and uploads it to the code review tool
Author does a self review and then requests that other reviewers read their code
Reviewers post comments. Some may be information, some may be required changes
The author makes changes based on reviewer feedback. The first three steps are repeated until no changes to the code are required
Reviewers find no issues and sign off on the change
The author is now allowed to commit the change if they have both resolved all comments and the change has been approved
If you’re writing a utility or a new library there is probably already an existing library that meets your needs
Code reviews are not times to review design decisions
Three aspects of review that require “approval” at Google:
“Correctness and comprehension check” to make sure the code does what the author claims it does
Is the code appropriate for this particular part of the codebase?
Approval from a "language readability" expert
Often, it is one person doing all three items, but separating the duties allows the process to scale
Code owners, who own certain parts of the codebase, should be viewed as stewards for that code
Strict processes don’t work well in dynamic companies that need to respond quickly
Finding defects earlier in the processes makes it less costly to fix them
Reviewer should not propose changes based on personal opinion
Reviewers can propose alternatives but only if they increase code comprehension
Perfect is the enemy of good
Thank you for your time and attention.
Apply what you've learned here.
Enjoy it all.
© 2021 Josh Turgasen
All product names, logos, and trademarks are property of their respective owners