A module containing a loose collection of mostly unrelated functions, that would be my definition of a Helper module. The name helpers kind of gives it away, it shows we weren't able to find a terse expression of the module's purpose.
Maybe their haphazard construction makes helper modules a bit unlikeable. They don't have great designs. But I like them anyway, because I think they fill an important niche in the wider ecosystem that is a codebase. They allow us to remove duplication without doing any api design work, at least not yet.
Api design is hard (I wrote about this before), and doing a good job requires plenty of example usages, to test our design as we create it. When we first spot some duplication it is unlikely to already be so pervasive that enough data for a good design exists. Given insufficient data, duplication is better than a bad abstraction. And after duplication, adding a helper might be the next least-worst option.
What happens next depends on usage of the helper. If it grows we might at some point design that abstraction using all the example use cases we now have. If usages remain constant we'll likely never look at the helper again. And if usage drops to a single callsite we can move the helper back to the module where it is called. One fewer helper, and one fewer layer of indirection!
Top comments (0)