O que separa o júnior do sênior é o pleno :D Ok, falando sério, o que conta p... · maniero

O que separa o júnior do sênior é o pleno :D Ok, falando sério, o que conta para determinarmos se a pessoa é iniciante ou experiente (mas as pessoas não experientes de forma correta, chamam de júniores e sêniores, que é só uma classificação de RH), é a pessoa saber criar algo de valor hoje e facilitado para amanhã, sem desperdícios desnecessários e fazendo escolhas que entregam os melhores resultados. O que o experiente não faz é seguir receitas de bolo, ou seja, não fazer algo sempre porque alguém disse que é para ser assim.

Então muitos dos artigos, livros, palestras e outras fontes, podem estar vendendo uma ideia específica, e que pode ter muito valor, mas é comum elas não demonstrarem que não deve ser usado sempre daquele jeito.

Assim como vender o DRY como solução única está errado, vender outras coisas como a melhor estratégia sempre, também é errado.

A minha experiência mostra que o DRY é uma das coisas mais importantes (talvez a mais) de seguir na programação, em organização de dados, documentação e outros aspectos até fora da engenharia de software. Mas é claro que ele não funciona bem se adotado errado. Já deveria ser um pressuposto que DRY errado não é DRY. Veja mais: https://pt.stackoverflow.com/q/120931/101.

Em função de muitos erros assim alguém um dia escreveu algo falando sobre abstrações erradas. E é correto dizer isso. Mas não podemos seguir cegamente alguma regrinha para não fazer DRY, por exemplo, não faz sentido esperar aparecer a terceira ocorrência. Se deve ser DRY deveria ser mesmo com uma ocorrência, ou seja, você cria a abstração porque ela é adequada, mesmo que acabe nunca tendo uma segunda ocorrência. Inclusive porque deve eliminar isto: https://pt.stackoverflow.com/q/354926/101.

Quando se fala em ter 3 ocorrências, parece que está se confundindo DRY com repetição. E porque deveríamos aceitar duas cópias de algo que é canônico? Porque você teria dificuldades de manter a integridade do conceito com 3 ocorrências, mas não com duas?

Por isso pegar requisitos é tão importante e difícil, que exige muita experiência qualitativa. E mesmo assim, será comum as pessoas errarem, temos exemplos de monte nos produtos mais populares e criados por pessoas perto da genialidade. Se está difícil entender a abstração, use técnicas para melhorar isso, faça protótipos, discussões abertas, aprenda fazer as perguntas certas, use ferramentas que possam ajudar (algumas podem atrapalhar, depende de como se usa, oooiiii IA), ache a abstração certa e tente validar melhor antes que não possa mais mudar. E não tenha medo de criar outra abstração evoluída se no futuro for necessário.

Em alguns cenários é o adequado, em outros pode ser que esperar pela terceira ocorrência ou até mais seja mais adequado. Não tem fórmula mágica, só a experiência determinará o melhor caminho.

O primeiro vídeo do meu canal falará justamente sobre essa questão de seguir "boas práticas" ser uma péssima prática (calma, quando você ver o conteúdo, verá que não é maluquice).

A falta de abstração onde precisa é intrinsicamente a abstração errada.

Só uma pessoa inexperiente acha que é fácil desfazer uma duplicação. Isso foi escrito por uma pessoa que teve uma experiência de programação na vida em ambiente de mainframe, que muito diferente de como fazemos software hoje em dia e depois em ambiente acadêmico, aí ele virou professor/consultor. Algumas más línguas costumam dizer que quem sabe faz, quem não sabe, ensina :D Por isso precisamos saber de onde vem a fonte, precisamos questionar a motivação e a capacidade da pessoa que prega algo.

Não quer dizer que a regra esteja errada, só que ela é uma simplificação. Tem cenários que ela pode ser ótima, mas esses cenários são cada vez menos prevalentes.

Eu tenho extensiva experiência em código duplicado e na maioria dos casos é tão trágico que reescrever tudo começa parecer algo mais adequado do que tentar consertar as abstrações.

Quando se fala de DRY como se fosse repetição já sabemos que a abstração errada será feita. Sem entender o conceito corretamente, o problema ainda é muito mais grave do que duplicar.

Tem até cenários que fazer sem engenharia alguma dá certo.

Sabe quando as pessoas falam que o código deve dizer o que ele faz em vez de pôr um comentário? Então, só dá certo fazendo as abstrações certas, mesmo que use apenas uma vez.

Quem faz errado poderá fazer com 2, 3, 4 ou muito mais ocorrências. Talvez a maior deficiência que programadores têm hoje em dia seja criar abstrações, independente de DRY. Olhe para as bibliotecas padrões das linguagens. Olhe para os casos que recriaram alguma API porque a original foi mal feita. Adquira experiência com o erro dos outros (bons) programadores.

Nem todo mundo concorda que o SQL é a abstração perfeita, até porque foram colocando uma batelada de novas formas de uso para compensar a abstração ruim.

Tem casos que oferecer algo com maior abstração e algo menos abstraído para o consumidor usar o que for melhor em cada caso é a solução adequada.

Ninguém sabe o que é legado. Tem tantas definições que ele pode ser visto de formas muito diferentes por pessoas diferentes em momentos diferentes. Ah, como um DRY aqui faz falta...

A frase acima usada para definir legado é recursiva, porque dívida técnica é você ter adquirir mais problemas que pagar soluções.

Acho que não conseguirei acompanhar o clube para avaliar se o encontro foi na direção certa, espero que tenham percebido que o livro não é estabeleceu uma verdade absoluta, apenas deu uma ideia interessante e útil para alguns casos, ou seja, é bom saber que existe, melhor ainda saber que não vale para tudo. De qualquer forma pouco depois que publiquei percebi que o clube não pode ser levado a sério, belo clube que só pode existier uma verdade (ironicamente acaba sendo a abstração errada por não permtir informação divergente).

Algumas pessoas para ouvir: Fabrice Bellard, Walter Bright, Casey Muratori, Andy Kekkey, Jonathan Blow, Mike Pal, Guy L. Steele Jr., Dave Cutler, Matt Godbolt, Howard Chu, só para dizer alguns que são pouco conhecidos.

Pode ajudar: https://www.tabnews.com.br/maniero/faq-do-programador-perdidao.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).