code-architecture-wrong-abstraction

Apply the Rule of Three during refactoring: wait for at least three similar occurrences of duplicated logic before extracting a shared abstraction, ensuring the pattern is stable and preventing premature design complexity.

To revert a wrong abstraction, follow a remediation workflow that inlines the abstracted logic back into its original modules, allowing independent patterns to stabilize before attempting a correct refactoring extraction.

Criteria for abstraction require evaluating whether behavior is consistent across all occurrences, verifying pattern stability, and ensuring the shared utility will not create complex, hard-to-maintain dependencies across modules.

Premature refactoring creates hard-to-maintain code by forcing wrong abstractions, coupling unrelated modules through shared utilities, and complicating future modifications when the duplicated logic inevitably diverges.

Code duplication is acceptable in API design and shared utilities until the Rule of Three is met, because preserving duplication initially prevents wrong abstractions and allows proper design patterns to emerge naturally.

Evaluate repository-wide code duplication by applying the Rule of Three, assessing behavior consistency across modules, and deciding whether to preserve the duplicate logic or extract it as a proper shared utility.