Web Directions Year round learning for product, design and engineering professionals

Refactoring Components

As much as we all like working on greenfields projects, most of the work we actually do is on existing codebases. And existing codebases have technical debt. Technical debt makes code hard to modify. Being hard to modify slows down to development. So, how do we deal with this? We refactor!

But, refactoring is an inherently risky process. It’s very easy to break things in any complex system, especially if the test coverage is less than ideal. Worse, it’s possible to ruin users’ experience by accidentally fixing bugs that their workflows had come to rely on. To combat this we need to ensure that our refactor doesn’t change the existing behaviour in any way, while also leaving us free to add new functionality.

We’re going to have a look at how to decide when we actually should refactor, and how we can use tests to ensure we maintain the existing behaviour. We’ll have a look at our options for testing JSX, and the pros and cons of snapshot tests. And we’ll finish up with a demo, putting it all together.

Erin Zimmer

Erin is a Google developer expert with over 15 years experience in a variety of languages, from JavaScript to Model204 (no, nobody else has heard of it either). She is currently a senior web developer at CashApp. She is an active member of the Melbourne developer community, and has spoken at conferences around the world. If you see her at a conference, she’ll probably have knitting needles in hand.