At work I keep seeing cases where there is overlap in common behavior but not completely. Special cases take a simple routine and wrench it through with conditions.

With React components, it’s often easy enough to split out the separate cases as their own components or, more recently, maybe push the differing behavior into individual hooks.

Some of the uglier cases are in Redux reducers, action creator functions, or async API-calling code. These functions start small and simple, but as the requirements grow and change over time these streamlined functions quickly grow branches, and those conditions then grow their own complexities in due time. Eventually it becomes a dense forest of possible code paths where bugs grow freely.

I’ve been trying to tame some of those areas recently by simply trying to separate what is common from what is different. A wonderful benefit of doing that is being able to clearly see what is different just from how the code is structured.

I’ve come to look at significant branching as a code smell, and try to refactor so that the branching happens once, up front, where you pick from a handful of top-level functions or objects that themselves are focused & single-purpose. I think that insight came from Sandi Metz & her 99 Bottles book; it’s an enormously powerful tool, and so far has been a great help.

Interestingly, Javascript’s prototypal inheritance is quite well suited for this kind of thing.

Duplication is useful when it supplies independent, specific examples of a general concept that you don’t yet understand.

--Sandi Metz, 99 Bottles

You can’t create the right abstraction until you fully understand the code, but the existence of the wrong abstraction may prevent you from ever doing so. This suggests that you should not reach for abstractions, but instead, you should resist them until they absolutely insist upon being created.

--Sandi Metz, 99 Bottles

I see that Sandi Metz has a new edition of her 99 Bottles book out, with new JavaScript & PHP versions as well as the classic Ruby. I'll have to read it. I'm a big fan of Sandi's, and her work tends to be rich with insights and well-formulated principles about coding & program design. Even if it's an OO-focused book, and my preference is more FP focused these days, it's still a good bet that the book will be more than worth the time to work through it.

Good Sandi Metz post: in software it's important to get the abstractions right, even if it comes at the cost of some duplication. Over time, the wrong or broken abstractions cause way bigger problems than duplication. Ideally you won't have either problem, but if you have to have one then choose the lesser evil of duplication if it enables cleaner abstractions.

"Every practice we use as part of our work puts forces on us, and generally those forces can push us toward or away from more successful ways of doing things." --Ron Jeffries