“Don’t Repeat Yourself” é um dos primeiros princípios que aprendemos, e justamente por isso é um dos mais mal aplicados. Vemos duas linhas parecidas e corremos para criar uma função compartilhada. Às vezes isso é um erro.
O custo oculto da abstração
Quando você une dois trechos de código que parecem iguais mas respondem a necessidades diferentes, cria um acoplamento. No dia em que um dos dois casos muda, você adiciona um parâmetro, depois um if, depois outra flag… até que a “abstração” fica mais difícil de ler que o código duplicado original.
A regra prática
Sandi Metz resume perfeitamente: “prefira a duplicação à abstração errada”. E a famosa regra de três:
Não abstraia na primeira repetição. Nem na segunda. Na terceira, você já tem informação suficiente para ver o padrão real.
A pergunta certa
Não é “este código se parece?” mas “esses dois lugares mudam pela mesma razão?”.
- Se vão sempre mudar juntos → abstraia.
- Se podem evoluir separadamente → deixe duplicados, mesmo que hoje pareçam idênticos.
É a diferença entre duplicação incidental (coincidência) e real (mesma regra de negócio).
Conclusão
DRY é uma boa heurística, não uma lei. Um pouco de WET (“Write Everything Twice”) deliberado muitas vezes produz um código mais fácil de mudar que uma abstração forçada. Otimize para a mudança, não para a coincidência.