Por que não se deve remover duplicação de código cedo demais
- Aplicar o princípio DRY (Don't Repeat Yourself) de forma rígida demais pode causar abstrações "prematuras", tornando mudanças futuras mais complexas
- É preciso pensar se a duplicação é realmente desnecessária ou se se trata de funcionalidades que vão evoluir de forma independente com o tempo
- Mesmo que funções ou classes pareçam idênticas, elas podem ter contextos e requisitos de negócio diferentes
- Mais importante do que deixar o código mais curto é pensar se o propósito da função continuará válido ao longo do tempo
- Riscos da abstração: quando há chance de as funcionalidades evoluírem de formas diferentes, a abstração pode acabar sendo prejudicial
- Ao projetar uma abstração, não se deve acoplar cedo demais comportamentos que, no longo prazo, podem evoluir separadamente
- Em caso de dúvida, é melhor manter os comportamentos separados até que, com o tempo, surjam padrões em comum suficientes para justificar o acoplamento
- Em pequena escala, pode ser mais simples gerenciar a duplicação do que resolver a complexidade de uma abstração prematura
- No início do desenvolvimento, vale tolerar um pouco de duplicação e esperar antes de abstrair
- Requisitos futuros muitas vezes são imprevisíveis
- Vale refletir sobre o princípio YAGNI (You Aren't Gonna Need It)
- Talvez a duplicação nunca se torne um problema ou, com o tempo, deixe clara a necessidade de uma abstração realmente bem pensada
10 comentários
Em primeiro lugar, a aplicação de DRY deveria ser feita reduzindo repetições quando elas de fato existem,
mas, se pensamos no código tendo DRY como critério antecipado, isso parece uma aplicação equivocada.
Entre as opiniões no Hacker News,
a que mais me representa é esta:
o mal-entendido sobre o princípio DRY é que ele serve para evitar duplicação de informação/conhecimento, e não duplicação de código. Se o foco ficar apenas na duplicação de código, isso pode levar a uma otimização desnecessária.
Na fase de transição, a gente não costuma ter muito esse tipo de preocupação? Como não existe código perfeito, ficar pensando nisso o tempo todo provavelmente faz parte do nosso trabalho. Acho que depende muito do caso.
Ultimamente, têm aparecido com certa frequência textos com um olhar cético sobre estruturas com alto grau de abstração.
MSA, código limpo, SOLID, DRY etc...
Acho que as pessoas talvez estejam ficando cansadas desses termos.
Na verdade, tudo isso são apenas referências para consultar quando se está pensando em escrever um código fácil de ler, fácil de entender, sem vazamentos de memória, sem erros e rápido...
Basta aplicar com bom senso, adequando bem à situação de negócio em que você se encontra agora.
https://velog.io/@kineo2k/…
Texto excelente.
Parece ser ainda mais importante especialmente na transição do modelo waterfall para o modelo ágil.
É ágil, mas tentam prever demais o futuro.
Não deixe o código DRY cedo demais
Quão cedo é “cedo demais”?
A resposta é muito simples. Se você fizer isso logo de cara, é “prematuro”.
A questão um pouco mais difícil é: quando fazer isso para que não seja “prematuro”?
É um trocadilho, mas se simplesmente não fizer isso desde o início, então não vai estar sendo “apressado”, né? ^^;
Sim, especialmente no ágil
Opinião do Hacker News
Aplicação inicial do princípio DRY: É bom aplicar o princípio DRY desde o começo. Em vez de tratar dados semelhantes separadamente, é mais eficiente usar uma base de código comum.
Prioridade das melhores práticas: Nem todas as melhores práticas têm o mesmo peso. É importante priorizar legibilidade e coesão. Escrever código é um processo de escolher as práticas mais adequadas.
Mal-entendido sobre o princípio DRY: DRY não trata de evitar duplicação de código, mas sim duplicação de informação/conhecimento. Focar apenas na duplicação de código pode levar a otimizações desnecessárias.
Problema de reutilização: Há casos em que uma funcionalidade específica não é reutilizada em outros contextos. É preciso uma abordagem melhor para evitar trabalho duplicado.
Problema de soluções DRY complexas: Às vezes, código repetido é melhor do que uma solução DRY complexa. Aplicar DRY cedo demais pode causar problemas estruturais inesperados.
DRY não é uma melhor prática: Repetição muitas vezes é um sinal de que abstração é necessária. Aplicar DRY indiscriminadamente é um erro comum entre engenheiros de nível intermediário.
Exemplo simples de código: Duas funções podem ser combinadas em uma só função. É importante explicar claramente os prós e contras da refatoração.
Problema de manutenção de código DRY: Código DRY pode se tornar complexo e difícil de manter. Já o código WET é simples, mas suas mudanças são previsíveis.
Efeitos colaterais do princípio DRY: O princípio DRY pode tornar a base de código complexa e difícil de manter. Alguns livros de clean code tiveram um impacto negativo na indústria.
Generalização e desempenho: A generalização pode impactar negativamente o desempenho. Duplicar código ajustado a padrões específicos de dados pode ajudar na otimização de performance.