Don’t Repeat Yourself (DRY) é um princípio de desenvolvimento de software, cujo objetivo principal é reduzir a repetição de código.
Write Everything Twice (WET) é uma abreviação arrojada para significar o oposto, ou seja, código que não segue o princípio DRY.

Um programador que se esforça para manter seu código DRY, portanto, não repeti-lo, geralmente segue a melhor prática. Mas há momentos em que adicionar um pouco de WET ao seu código poderá facilitar a vida de todos os programadores.

O computador já tem muito o que fazer, então, porquê escrever código que fará com que perca mais tempo na compilação?

A memória também é fundamental. Esgotar a memória, ou usar a memória desnecessariamente, é uma forma de colocar o código no lixo. Tornando o código WET pode também ajudar a chegar lá – ao lixo! Os primeiros tempos dos computadores, quando o armazenamento nem chegava a um kilobyte, recorda-se? Nada é ilimitado.

= DRY – Exemplo Simples =

Supondo que temos muitos lugares no código que precisam de ser executados com base na função do user atual. Por exemplo, criarPagina() só pode ser executado se o user for um editor ou administrador, apagarPagina() somente se o user for um administrador, etc.

Em vez de disseminar a lógica de verificar a função de um usuário em criarPagina() e apagarPagina(), podemos usar uma única função permissao() como abaixo.

// busca do utilizador
$utilizador = utilizadorActual();

if (permissao($utilizador)) {
// pode apagar a página
} else {
// bloqueia a função de apagarPagina()
}

Mantendo a lógica de permissao() num local, evita assim a duplicação e também habilita a reutilização do código. A vantagem adicional é a separação da lógica, ou seja, criarPagina() e apagarPagina() não precisam de saber como a permissão é verificada.

= Vantagens do DRY =

1. Manutenção
O maior benefício do uso de DRY é a manutenção.
Se a lógica da verificação da permissão foi repetida em todo o código, torna-se difícil corrigir os problemas que surgem no código repetido. Quando se corrige um problema num lugar só, pode-se facilmente esquecer de corrigi-lo noutras ocorrências.
Além disso, se precisar de modificar a lógica, precisará de copiar e colar em todo os sítios. Por ter código não repetido, só precisará de manter o código num único local. Novas lógicas e correções de bugs podem ser feitas num sítio apenas, em vez de em muitos sítios. Isto torna um software robusto e confiável.

2. Legibilidade
Frequentemente, o código DRY é mais legível. Isso não se deve ao próprio princípio DRY, mas ao esforço extra que o programador dedica ao código para fazê-lo seguir certos princípios, como o DRY.

3. Reutilização
O DRY promove a reutilização de código porque estamos a utilizar duas ou mais instâncias de repetição de código num único bloco de código.
O código reutilizável é pago a longo prazo, à medida que acelera o tempo de desenvolvimento.

4. Custo
Se a gestão da empresa precisar de ser convencida sobre investir mais tempo na melhoria da qualidade do código, então é isto: mais código custa mais.
Mais código demora mais tempo para os técnicos manterem e resolverem erros. Mais tempo para desenvolver e mais erros tornam um cliente infeliz.

5. Testes
Quanto mais caminhos e funções tiver que cobrir utilizando os testes, mais código será necessário escrever para os testes.
Se o código não for repetido, apenas precisará de testar um caminho principal, sendo que, comportamentos diferentes ainda precisam de ser testados, obviamente.

= Cuidados a ter =

Com todas as vantagens de usar o DRY, existem, porém, algumas armadilhas:

1. Nem todo o código precisa de ser “misturado” numa única porção. Algumas vezes, duas partes do código podem parecer semelhantes, mas com diferenças subtis. Quando misturar essas porções de código numa só e quando deixá-las separadas, deverá ser cuidadosamente pensado.

2. Se o código estiver “muito seco”, torna-se difícil de ler e compreender. Muitos programadores tentam aplicar o princípio DRY, mesmo quando há apenas uma instância de um bloco de código.

3. Frequentemente esquecido, o DRY não se limita apenas ao código. Deve ser aplicado em igual medida ao design da base de dados, documentação, código de teste, etc.

= Opinião Pessoal =

Pessoalmente, “as coisas parecem mais feias” quando um código é muito WET. Muitas vezes, faz-me sentir de imediato que o código não está limpo, organizado e que tem, por isso, má leitura.
Mais coisas, como implementar OOP (Object Oriented Programming) – Herança, polimorfismo, são boas práticas para evitar o código WET.

PS: O código não é temperamental!