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

  • Many ideas in this chapter trace back to the fact that it's easier to have a single team make all changes across a code base instead of updating their small part of the system and then calling on all users of that system to update their code
  • As the number of engineers grows the size of the largest possible change across a code base decreases
  • In other words, many smaller changes vs a single large change
  • LSC (large scale changes) are defined as a set of changes that are logically related but cannot be practically submitted and applied in a single commit
  • The ability to make LSCs depends on your repo topology. In your organization it may not even be possible to do LSCs
  • At Google they tend to use LSCs for...
    • Replacing deprecated library features
    • Changing common anti-patterns
    • Moving users from an older system to a new one
    • Enabling low-level infrastructure changes (compiler upgrades)
  • The advantage of creating a workflow for LSCs is that is not only scales up but scales down as well (the same workflow can make millions of changes or dozens)
  • The team that has the knowledge to make the change is the one who makes the LSC. A team that updates their library cannot make all dependent teams upgrade their code immediately.
  • LSC can be used to change naming convention discrepancies and solidifying naming conventions
  • Sometimes LSCs are impossible because the infrastructure cannot handle the changes of thousands of files at once
  • Another reason why LSCs may be impossible is due to unavoidable merge conflicts that happen when thousands of engineers are working on the same codebase
  • Haunted Graveyards (systems that nobody knows about or wants to touch) are not conductive to LSCs
  • Small, independent changes are easier to validate
  • Engineer time spent tracking down test failures is more valuable than the compute time used to run the tests
  • At Google it's common for 10-20% of all changes to be LSCs
  • Breaking a LSC into separate shards or chunks makes it easier for code review and testing
  • When making LSCs also consider that you may need to make the change to automatically generated code and not just the code that lives in the repo
< BACK NEXT >
Tweet


   


   

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