Software Engineering at Google Chapter #22 - Large Scale Changes (2 of 3)

  • Consider making aliases for the first wave of a LSC and then making the text replacement later
  • When making LSCs also consider the code review burden that it puts on the teams who's code has changed
  • Each LSC should have a good reason behind it because of the burden that it puts on the code reviewers
  • An example of a bad LSC is correcting a common typo with no way to automatically correct that typo in the future. This LSC will create little or no value and will need to be re-run again in the future as humans will continue to make errors
  • Good FAQs and a history of documented success is what makes a culture of LSCs smooth, understandable, and embedded into the minds of employees
  • For LSCs to be possible you need insight into your code-base using tools talked about in Chapters 17 and 20. If you can't view and analyze your codebase you cannot make LSCs because they will not succeed in changing all the code that needs to be changed
  • The change management process is an essential part of LSCs. This includes notifications, testing, reviewing, and committing.
  • A strong testing infrastructure is important in part because LSCs are (mostly) not approved by human reviewers
  • Programming language features such as type aliasing and forwarding functions help greatly with LSCs
  • Static typed languages make LSCs much easier
  • Automatic language formatters are an essential part of making LSCs succeed
  • The LSC process is broken down into four phases...
    • Authorization
    • Change creation
    • Shard management
    • Cleanup
  • You should design new systems with a forward migration path in mind from the beginning
  • The authorization phase...
    • Fill out a document explaining the reason for the change, the benefits it provides, it's impact, etc
    • Documenting the answers to these questions forces the author to think more deeply about the change and think about it's overall impact
    • For most mechanical LSCs it's best to have a single person do automated reviews instead of each consumer of the changed code to review the automated changes that were made to their code
    • A committee reviews the change request document and approves, denies, and/or suggests changes
    • The committee also acts as an escalation path if a code owner who's code is changed by a LSC disagrees with the change



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