💾 Archived View for idiomdrottning.org › changing-inflexible-code captured on 2024-08-31 at 14:03:14. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Changing inflexible code

There is this Ron Jeffries quote:

I once saw Beck declare two patches of almost completely different code to be “duplication”, change them so that they WERE duplication, and then remove the newly inserted duplication to come up with something obviously better.

And it’s great and I’m into it. I read it back in the day and I’ve since lived that same dream myself, many times.♥︎ Duplication is the one thing I always do wanna extract.

Extracted duplication is great when you later need to make the same kind of change to both places. You have a single point of truth.

However, you need to know how to inline. Always keep inlining in mind, because you’re gonna need it when you need to make different changes to both places.

Take the reverse of that Beck story:

Declare two calls to the same method to be two patches of almost completely different code, change them so that they are different, and remove the extraction.

If this becomes a tool you’re comfortable with using in both directions, code is going to become flexible and strong, even legacy code.

I wanted to extract a repeated long weird incantation like get into frobnicate lambda line noise rho rho rho your boat iota down the stream, and my pal was like “No, don’t introduce a new abstraction here. Every experienced programmer can instantly grok that idiom you wanted to extract.”

I’m like, wow, that’s great. I’m happy to learn it. But what every experienced programmer need to learn is get comfortable with inlining and extracting. Get as comfortable with refactoring basics as a prose writer is changing two words around.