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.

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

Maintaining large codebases

By Jack Franklin

Maintaining large codebases

  • 25

More from Jack Franklin