Software Engineering at Google Chapter #9 - Code Review (2 of 3)

  • Code change should be comprehensible to other engineers
  • Other engineers provide feedback from a unbiased perspective. This is the first test to see if the code is readable to a non-author
  • Large or small, each question about the comprehension of your code is valid as the question will likely be re-asked over and over through time
  • Consistency across the codebase
  • Don’t be clever, keep code simple
  • If a software design pattern is used the same way in all code it is much easier to automate refactoring
  • Remind the author that the code is not “theirs” but the collective’s
  • Validate the author if they have good code to create anti-imposter syndrome
  • Forces engineers to make sure their ducks are in a row and it’s not just “good enough” code
  • Enables knowledge sharing
  • Self explanatory
  • Provides a historical record of the code review itself
  • “Shift left” means finding bugs earlier in the process (a timeline goes from left to right, thus “shift left”)
  • Code Review Best Practices:
    • Be Professional and polite
    • Trust and respect
    • When in two options are essentially the same, defer to the author’s choice
    • Only suggest changes if the code is deficient and not based on personal preference
    • Ask why something was done the way it was instead of saying it’s wrong
    • Do the entire code review at once, don’t keep going back and forth over newly-found single items
    • Treat each reviewers comment as a “to do” - some action must be taken
< BACK NEXT >
Tweet


   


   

Thank you for your time and attention.
Apply what you've learned here.
Enjoy it all.