Thread by @Steve8708

Don't be that teammate who blindly refactors code and only makes things worse.

Let's look at some good vs bad refactoring patterns with real examples 🧵

Let's take this code.

I hired a developer once that saw us calling this `functions.runWith(...)` repeatedly with different options and decided to consolidate it all into one createApi function

This new, consolidated code, had a huge issue.

Can you see it?

When we started deploying these APIs, they began breaking left and right.

Why?

Because different functions needed different options timeout and memory options.

The inconsistency was not a mistake, it was intentional and ignored by this dev causing us a lot of headaches.

A better approach would've been to pass through the options like so:

Now let's take this code.

Tbh its completely fine, but depending on your preferences you may think it would look nicer with a more functional approach.

I hired a dev once that all of the code they touched they refactored to use a very opinionated functional style using Ramda and other libraries

Needless to say, most other devs on the team were not familiar with Ramda and didn't love working with it.

A better refactor would've been to simply do this.

This code is cleaner, more functional, doesn't add new libraries, and better matches the other code in the codebase.

I hired another dev once that loved to over abstract things.

They would've refactored that original for loop to look more like this.

Every time you worked with their code there were just so many more layers than necessary to do simple things.

If one feels its so important to create clearly separated and named functions for each step in the flow, this would be a much better solution that is simpler and more conventional within the existing codebase:

Too many times I've seen devs assume that just because they didn't understand some code, it must be bad code and they should just refactor it before learning it.

Let's take this code:

I've worked with devs before that would just blindly assume this is better code.

It's so simple and beautiful, right?

Well, most code starts out simple.

But we added more layers for a reason, and blindly deleting them is rarely answer.

A better approach would be to do this: create a basic cache manager.

This small abstraction allows us to keep caching in our implementation, but clean out the JSON/localStorage logic from the function itself.

No more performance regressions.

Don't forget that business context matters too.

I once worked at an ecommerce company that was on an eight year old Java framework that didn't even have online documentation anymore.

I convinced the business to move us to something more modern and fast... Angular.js

We built a massive single page app before I fully understood that this was an SEO-driven business where first page load times matter a *lot*.

SEO and conversions tanked, and the business lost a lot of money.

In hindsight, server side rendering was essential for this business:

Some tips and tools to refactor better.

1. Write tests to ensure updates match the prior behavior
2. Use type-safe languages to avoid silly mistakes
3. Get feedback on your changes via code reviews

Also, use tools that can understand and match your existing coding style and reuse existing code.

E.g. when turning Figma designs into code Visual Copilot by @builderio will reuse your existing components and match your specific coding style via custom instructions.

Oh you're still here?

Well I have something for you.

More examples and depth on this topic in my full blog post: builder.io/blog/good-vs-b…

Theres also a YouTube video on this by yours truly if you like vids