// PATCH №042 · ENGINEERING
The cardinal sin of refactoring is acting on a sample size of two. You see two functions that look 80% similar, you extract a shared helper, and now there’s a third caller in your future who will not match the abstraction. The helper grows flags. The flags grow conditionals. Eventually someone reverts to a copy-paste version because reading the helper takes longer than rewriting the logic.
When duplication is correct
Repeated literals are not the same as repeated logic. Two functions that compute different things via similar shapes are coincidence, not commonality. The Rule of Three exists because three samples are usually enough to show whether the similarity is structural or accidental.
If the abstraction’s name has the word ‘Helper’ or ‘Util’ in it, you abstracted too early.
Signals that you over-abstracted
- The helper’s parameter list grows every quarter
- Most call sites pass the same configuration block
- New contributors copy-paste from a different call site instead of using the helper
- The helper is mocked in 60% of tests that don’t even hit its core logic
When you see those signals, the cheapest fix is usually inlining the helper back into its callers and starting over with a tighter scope. Three honest inline copies beats one dishonest abstraction.