Atomic Spin

Software developers are great at recognizing patterns. Talvez seja uma habilidade inerente que nos atrai para esta profissão. Ou talvez seja o processo de escrever software que desenvolve esta habilidade. De qualquer forma, “não se repita” (DRY) é uma aplicação natural desta habilidade.

No entanto, a repetição em si mesma não é o inimigo que este princípio faz com que seja.

Não se repita

Por mais intuitivo que “não se repita” possa ser, O Programador Pragmático resume-o desta forma:

Todos os conhecimentos devem ter uma representação única, inequívoca e autoritária dentro de um sistema.

Não é difícil imaginar os benefícios de reduzir ou eliminar a repetição.

• Sem duplicação significa menos código para manter. E se o melhor código não é nenhum código, isto soa como uma coisa boa.
• Uma única fonte de verdade elimina a possibilidade das coisas saírem de sincronia. Alguma regra de negócios mudou? Atualize-a em um lugar, e seja feito.
• Código é reutilizável. Tem um processo que é compartilhado por três coisas, e você está adicionando uma quarta? A maioria do trabalho já foi feito.

Some Sometimes Repeat Yourself

Se você for muito zeloso em reduzir a duplicação aparente pode criar mais problemas do que resolve. Eu digo “duplicação aparente” porque às vezes as coisas que parecem semelhantes não estão realmente relacionadas. Por exemplo, duas estruturas de dados com propriedades e tipos idênticos podem ser as mesmas estruturalmente mas não semanticamente.

Uma estratégia comum para reduzir código duplicado é fatorar as partes comuns e escondê-las atrás de uma abstração. Mas um efeito colateral indesejável disso é que ele acopla qualquer coisa usando a abstração. Qualquer mudança na abstração afeta todos os seus consumidores. E da mesma forma, a abstração pode precisar ser dobrada para se ajustar aos requisitos de apenas um consumidor.

Este aumento no acoplamento também vem com uma diminuição na flexibilidade. Digamos que você tem um processo que é usado em três lugares. É quase o mesmo em todos os três lugares, com apenas algumas diferenças importantes. Então você implementa o processo como um único módulo que leva alguns poucos parâmetros para cobrir as diferenças.

Tweaking the process for just one of those use cases is now impossible: any change to one affects all three. Claro, você pode adicionar mais parâmetros (ou casos especiais!) à medida que os casos de uso divergem. Mas rapidamente se tornará impossível distinguir as partes importantes do processo da infra-estrutura que separa os casos de uso.

Questões a perguntar

Quando refactoring existing code or writing new code that may potentially be duplicplicated, I ask myself:

Is this a single piece of knowledge that has been duplplicated, or is this just infrastructure that happens to look similar?

Então você rummaged através do CSS e encontrou uma classe que por acaso tem apenas os estilos que você quer. Isso provavelmente não é razão suficiente para evitar definir outra classe.

Quantas vezes isso foi repetido?

até que uma coisa realmente redundante apareça pelo menos três vezes, eu seria muito cético em relação a qualquer repetição-redução que aumente a complexidade.

Diminuir a duplicação agora tornará mais difícil personalizar casos individuais no futuro?

Existe algo satisfatório em refacturar um monte de código de copiar e colar em algo mais simplificado e reutilizável. Mas bloquear o código tão apertado que qualquer alteração introduziria casos especiais não é um bom trade-off.

Se eu reduzir esta duplicação, qual é a relação entre o tamanho da abstração e o número de parâmetros que será necessário?

Bibliotecas e frameworks são ótimos porque fornecem código reutilizável com relativamente poucos parâmetros para personalização. Mas imagine uma função específica da aplicação para apresentar uma caixa de diálogo que cresceu e agora aceita 20 parâmetros. Qualquer que seja o benefício da repetição-redução que existiu quando tinha 2 parâmetros não existe mais.

Conclusão

Como com muitos princípios de desenvolvimento de software, “não se repita” é mais uma diretriz do que um mantra.