Não leve o DRY tão a sério
--
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ê
Para exemplificar a ideia, vamos imaginar um projeto Java e Spring com a clássica busca de produtos num banco de dados MongoDB, ilustrada pelo pseudo código a seguir.
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:
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
Mas vamos imaginar agora que um outro repositório de clientes “CustomerRepository” também necessita de queries que envolvem o documento de produtos. A boa desenvolvedora com o DRY em mente não vai querer repetir as constantes recém extraidas em “CustomerRepository”, certo?
Vamos então seguir à risca os conceitos de software aprendidos transferi-las para outra classe que poderá ser reusada:
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.
Top! 😃
A hora da manutenção
Segue a vida na sprint e mais um método precisa ser escrito envolvendo o atributo “price”. E outro envolvendo “type”…
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
Mas então o DRY é ruim?
É 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.
