Lessons learned maintaining large codebases
150, 000+
lines of "first party" JavaScript
15+
years of history, changes and developers contributing
Daily
deploys into Chrome Canary
If it's not tested, it's probably broken.
TypeScript compiler
Does the codebase compile?
ESLint
Are the changes consistent with our style?
Unit tests
Does the functionality work?
End to end tests
Are any of the user journeys affected?
Isolate your codebase into modules
CONFLICT: Merge conflict in network.js
CONFLICT: Merge conflict in network.js
If a standard isn't enforced it won't be followed
ESLint built-in rules
Is the code consistent?
ESLint custom rules
Does each file have the right license header?
Presubmit Checks
Are all the i18n generated strings up to date?
Change list (Pull request) checks
Does this CL have a bug associated with it?
Enable effective code review by automating
"I would prefer this to be indented by three spaces, not two"
"What's the reason for calling event.preventDefault() there? I'm finding this code hard to follow so it might be worth exploring alternatives.
Let the computer do what it's good at, so you can focus your review on what you're good at.
💻 code is formatted consistently
💻 all unit/end-to-end tests pass
💻 all the files have the correct license headers
💻 this change hasn't impacted code coverage negatively
💻 the files in this change follow our naming convention
👨💻 is this architecture going to cause problems in the future?
There's only so much you can plan
(but you should still plan, and plan again)
Upgrading DevTools' architecture to the modern web
youtu.be/BHogHiiyuQk
PLANNING
DOING
You have to be flexible to changes
"The networking module uses a different backend communication system so we need to revisit our migration plan"
"Turns out the elements panel doesn't use that buggy method so the impact isn't as bad as we feared"
Things take time
People
Teams
Features
Bugs
Lines of code
Risk
Thank You
fishandscripts.com
@fishandscripts
jackf.io/blog
@jack_franklin
Slides: jackf.io/talks/large-codebases