Existem casos excepcionais em que podemos aceitar código duplicado?

Sandi Metz, renomada engenheira de software e autora do ecossistema Ruby, tem uma ótima postagem no blog e uma conversa , onde ela também fala sobre a relação entre a duplicação e abstração. Ela chega à seguinte conclusão

duplication is far cheaper than the wrong abstraction

E eu concordo completamente com ela. Deixe-me dar mais contexto a esta citação. Às vezes, encontrar a abstração correta é muito difícil. Em tais casos, é tentador simplesmente ir para qualquer abstração para reduzir a duplicação. Mas depois você pode descobrir que sua abstração não é válida para todos os casos. No entanto, é caro mudar tudo de novo e seguir um caminho diferente (para uma explicação muito melhor, veja-a falar!).

Então, sim, para mim, há casos excepcionais, em que aceitar a duplicação é a decisão certa, especialmente quando você não tem certeza do que está por vir e é provável que os requisitos mudem. De sua postagem, considero que há muita duplicação agora, mas seus colegas sugerem que isso pode mudar e não combinar os dois aplicativos uns com os outros. Na minha opinião, este é um argumento válido e não pode ser desconsiderado em geral.

Se as pessoas começarem a raciocinar sobre design com as palavras "se amanhã" , isso geralmente é um grande sinal de alerta para mim, especialmente quando o argumento é usado para justificar uma decisão que inclui trabalho e esforço extras , para quem ninguém realmente sabe se isso vai dar retorno, e qual é mais difícil de mudar ou reverter do que a decisão oposta.

A duplicação de código reduz o esforço apenas por um curto período, mas aumentará os esforços de manutenção quase imediatamente, proporcionalmente ao número de linhas duplicadas de código. Note também que uma vez que o código é duplicado, será difícil remover a duplicação quando se verificar que esta foi a decisão errada, enquanto que se não duplicar o código agora, ainda é fácil introduzir a duplicação mais tarde se ficar preso ao DRY foi a decisão errada.

Disse que, em organizações maiores, às vezes é benéfico favorecer a independência de equipes diferentes sobre o princípio DRY. Se remover a duplicação extraindo as partes comuns de 95% das APIs, dois um novo componente leva a um acoplamento de duas equipes independentes, isso pode não ser a decisão mais sábia. Por outro lado, se você tiver recursos limitados e houver apenas uma equipe mantendo as duas APIs, tenho certeza de que será do seu próprio interesse não criar nenhum esforço duplo e evitar duplicações de código desnecessárias.

Note ainda que faz diferença se as APIs "Home" e "Agency" forem usadas exclusivamente por aplicativos totalmente diferentes, ou se alguém pode tentar escrever uma compilação de componente sobre as APIs que podem ser usadas em um "Home" contexto, bem como num contexto de "Agência". Para esta situação, ter as partes comuns das APIs exatamente idênticas (que você só pode garantir se as partes comuns não forem duplicadas), facilitará muito o desenvolvimento de tal componente.

Então, se houver diferentes subequipes, cada um responsável por cada uma das APIs, cada uma com um cronograma e recursos diferentes, então é hora de duplicar o código, mas não "apenas no caso" .

Duplicação para impedir o acoplamento . Digamos que você tenha dois grandes sistemas e os force a usar a mesma biblioteca. Você pode estar acoplando o ciclo de lançamento de ambos os sistemas. Isso pode não ser tão ruim, mas vamos dizer que um sistema precisa introduzir uma mudança. O outro precisa analisar a mudança e pode ser afetado. Às vezes pode quebrar as coisas. Mesmo que ambas as partes possam coordenar as mudanças, pode haver muitas reuniões, passando por gerentes, testes, dependências e o fim da pequena equipe autônoma.

Então você está pagando o preço do código duplicado para ganhar autonomia e independência.