Managing Technical Debt in JavaScript
The company I work for, Club OS, is undergoing a "growing-up"
phase.
A large challenge we face is addressing technical debt. The
front-end team has come together to create standards and practices
for working with untested, polluted JavaScript. I'm proud of the
documentation we put together, so here is some of it.
Gist: Modular Client Code
As we pursue debt recovery, we've also began
budgeting
for performance. I hope to share our progress in a few months.
My Work In the Wild
A lot of code that I write and review for Club OS is not visible
to the public. However, we recently prototyped a consumer facing
application. It's built using React and Redux, and is mostly
rendered client-side. A demo can be found here:
https://clients.club-os.com/locations/4559/schedule
Currently, source maps are available, so you'll be able to view
how we write code. I acknowledge the application has rough spots.
In the future, I'd like to spend more time on optimizing our
build, and improve how we organize synchronous actions through
Redux.
A few years ago, I open-sourced some code we use at Club OS. It's
going through a bit of an
identity crisis
at the moment. I've played around with some ideas, and I am
currently thinking documentation is needed over code changes. It's
something I wish to get back to soon.