como desenvolvedores, muitas vezes ouvimos frases clichés espalhadas como “Don’t Repeat Yourself”. Pegamos em ideias como esta e corremos com elas, às vezes um pouco longe demais.

recuar e avaliar por que fazemos estas coisas é útil. Então hoje, vamos olhar para uma ideologia alternativa à programação seca.

DRY is defined (according to Wikipedia) as:

Every piece of knowledge must have a single, un ambusive, authoritative representation within a system.

alguns destes podem ficar um pouco pedantes, mas isso pode ser útil quando se considera algo assim. Vamos lá quebrar as partes da frase.

cada peça

o que é”cada peça”? Podemos nunca repetir um nome variável? Uma entidade HTML?Ok, ok. Então podemos repetir <div>‘s sem muito problema e eu não acho que ninguém vai se ofender com isso. Mas isso levanta a questão-quando decidimos que algo se tornou um”pedaço de conhecimento”? Em Reagir, um bom exemplo pode ser um componente – mas é que PrimaryButton e SecondaryButton, ou significa uma generalizada Button classe? A resposta é geralmente considerada como “o que sua organização escolhe”, mas isso ainda pode deixar um bom pouco de ambiguidade em torno do que escolhemos abstrair.

conhecimento

Este é outro ponto ambíguo – o que definimos como conhecimento? Considere um elemento de botão estilizado usando algumas classes atômicas e reaja. Se um dev sênior levar 10 segundos para criar, eles podem não considerar que o conhecimento vale a pena abstrair. Mas para um desenvolvedor mais júnior que não conhece bem o sistema, esse conhecimento pode ser uma boa abstração. Caso contrário, eles podem ter que caçar as classes, lembrar-se de como os botões funcionam, e descobrir a sintaxe para um onClick. O conhecimento é relativo e usá-lo em uma definição acrescenta ambiguidade.

Update: Xander deixou o seguinte comentário abaixo. Eu acho que esse artigo faz um grande trabalho de explicar o que “conhecimento” deve significar.

apenas queria deixar isto aqui para as pessoas que estão interessadas.

“a SECO é de cerca de Conhecimento, a duplicação de Código não é o problema.”
verraes.net/2014/08/dry-is-about-k…

única, inequívoca, representação autoritária

“única” representação deixa muito a desejar. Do ponto de vista de um engenheiro devops, uma única representação pode ser uma aplicação inteira que eles precisam implantar. Para um dev frontend, isso pode ser um componente. E para um dev infra-estrutura, isso pode ser um método numa classe ou um endpoint API. Onde é que a linha é traçada?

também temos a palavra “sem ambiguidades” – mas como acabei de salientar, o resto desta frase define mais ambiguidade. “Autoritário” faz sentido – seu código seco deve definir exatamente o que faz e ser verdadeiro a essa definição. No entanto, isso não está explicitamente confinado ao código seco.

sistema

finalmente, temos o mundo “sistema” – isto volta para a declaração” single ” que discutimos há um segundo atrás. O que é um”sistema”? Na reação, pode ser um componente ou um Redux ação/componente/redutor. Em software contido, podemos estar a falar de uma cápsula inteira ou apenas de uma única instância.

no final do dia, DRY all para muitas vezes promove a pré-otimização, o que é desnecessário e às vezes realmente machuca sua capacidade de escrever código. Às vezes é mais difícil modificar um componente abstraído para se ajustar a um caso de uso específico. Você adiciona muita complexidade ou quebra esse componente em algo novo – que não é super seco. Não podes saber todos os casos de uso para o teu componente no primeiro dia.

uma alternative-Write Everything Twice (WET) programming

Instead, I proposal WET programming. Para mim A definição seria:

você pode perguntar a si mesmo ” não escrevi isto antes?”duas vezes, mas nunca três.

com esta definição, o foco afasta-se da optimização prematura e, em vez disso, permite-lhe repetir um código semelhante algumas vezes. Também muda o foco para uma reação mais intestinal. Ele permite que você tome decisões com base no caso de uso exato que você está olhando. Se você está construindo um aplicativo web, você provavelmente quer abstrair seus botões em um componente, porque você vai estar usando um monte deles. Mas se há uma única página que tem algum estilo especial (talvez uma página de preços?), então você não precisa se preocupar muito com a abstração dos componentes dessa página. Na verdade, sob este sistema, se você precisava de uma nova página que fosse semelhante àquela página especial, você poderia apenas copiar/colar e alterar o código que você precisa. No entanto, no momento em que isso acontece uma terceira vez, seu tempo para gastar um pouco de tempo abstraindo as partes que podem ser abstraídas.eu também acrescentaria esta estipulação (tanto para a programação molhada como seca):