Não leve o DRY tão a sério

Photo by Ryoji Iwata on Unsplash

Um dos conceitos mais frequentemente lembrados no desenvolvimento de software é o DRY: “don’t repeat yourself” ou “não se repita”.

Apesar de ser uma boa filosofia para se ter mente, defendo que ele não deve ser levado tão a sério.

Stay tuned!

Explico o porquê

Pseudo código que representa a busca de produtos em um banco de dados MongoDB

No pseudo código acima, é importante chamar atenção para a repetição dos nomes de atributos nas queries, como “active” (linhas 12, 21 e 33) e “name” (linhas 20 e 31).

O número de ocorrências da mesma string dispara um alerta no SonarQube, que berra para ser corrigido.

Para evitar o desalinhamento dos chakras e garantir números bonitos no SonarQube, vamos extrair essas repetições para constantes:

Busca de produtos com atributos representados por constantes

Podemos notar as contantes nas linhas 4, 5 e 6 e seu uso nos métodos. Muito bem, o SonarQube está feliz.

Adicionamos uma busca de clientes

Vamos então seguir à risca os conceitos de software aprendidos transferi-las para outra classe que poderá ser reusada:

Classe com constantes relacionadas ao documento de produtos no banco de dados

E o repositório “ProductRepository” é refatorado para usar a classe externa de constantes conforme o pseudo código a seguir. Repare nas linhas 12, 20–21 e 31–33.

Busca de produtos com atributos representados por constantes de classe externa

Top! 😃

A hora da manutenção

E é aí que começa o inferno da manutenção. Para cada query escrita, é preciso conferir na classe de constantes se os atributos já existem, copiar o nome da constante, voltar na classe do repositório e colar no novo método.

E legibilidade da query? Voltamos para as linhas 31–33 acima: não existe forma de constantes referenciadas serem mais legíveis do que o nome explícito do atributo!

Pode ser argumentado aqui que “ah mas se um dia o nome do attribute mudar, só existe um ponto de manutenção no código”.

Mas sejamos realistas: o que tem chance de ser modificado com mais frequência, nomes de atributos no banco de dados ou queries? Se o banco de dados mudar com mais frequência que as queries… tenho uma notícia pra você… o sistema está com sérios problemas!

Conclusão

É fato que princípios de programação ou padrões de projeto são bons GUIAS parar nos conduzir no caminho do bom código, porém é preciso pensar sobre eles ao invés de levar todos tão a sério e “ao pé da letra”.

O exemplo desse artigo foi criado com o objetivo de demonstrar uma situação em que ao evitar repetição estão sendo criados mais problemas que soluções. Apesar de não ser o único momento em que o DRY não compensa, não quer dizer que nunca deva ser usado.

Mas por que não experimentar repetir trechos de códigos pelo menos duas vezes antes de criar qualquer abstração? Ou aguardar a funcionalidade “amadurecer” para perceber se faz sentido ou não repetições? E ainda, analisar impactos na facilidade de manutenção e legibilidade?

Antes de criar abstrações, otimizações prematuras e arquiteturas excessivamente complexas é necessário considerar prós e contras e entender se a aplicação do conceito traz um benefício real ou se só satisfará métricas abstratas.

Um bom código não é aquele que aplica todos os acrônimos e conceitos bonitos da literatura, mas aquele que é fácil de manter e entender.

Software Engineer. Always learning.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store