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
    • NOTE: 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.