Uma das filosofias mais adotadas por programadores Ruby no mundo todo e amplamente evangelizada pelos maiores nomes da programação, independente da linguagem ou comunidade com o qual está mais envolvido é o “Don’t Repeat Yourself” (Não se repita, ou simplesmente DRY).

DRY é mais do que apenas uma boa prática de desenvolvimento, é uma filosofia que envolve evitar repetições. Trechos de código repetidos na maior parte dos casos (se não em todos) somente tornam nosso código mais obscuro e inconsistente. Quando repetimos trechos de código em nosso projeto ou mesmo em projetos diferentes, estamos aumentando a complexidade de gerenciamento e dificultando mudanças.

Ao criar código reutilizável estamos facilitando nossa vida no longo prazo. Se uma alteração importante é necessária para aumentar a segurança de seu sistema de autenticação, será muito mais fácil realizá-la se você estiver usando uma biblioteca única para este fim em todos os seus projetos. Mas imagine o trabalho que terá se cada projeto em sua empresa utilizar um sistema único de autenticação criado especialmente para ele.

Quando DRY é aplicado com sucesso em seu projeto ou empresa, a modificação de um único elemento não afetará nenhuma outra parte do seu sistema, com exceção de elementos intrincadamente relacionados.

O simples fato de criar bibliotecas não necessariamente significa que você está sendo DRY. Sistemas como o Enterprise Java Beans embora não exijam que você repita código em Java, lhe obrigam a duplicar arquivos de configuração. Isto não é ser DRY. (Uma nota aqui: Estou totalmente por fora do mundo Java e é possível que isto tenha mudado ou melhorado. Minha intenção é apenas exemplificar.)

O ActiveRecord do Rails é um excelente exemplo de uma biblioteca DRY. Não é necessário criar nenhum tipo de arquivo de configuração, e nem mesmo copiar e colar código entre seus modelos.

“Don’t repeat yourself” não é somente sobre duplicar trechos de código, também tem muito a ver com o comportamento funcional do seu código. Composição e herança em linguagens orientadas a objetos foram criados exatamente para suportar este tipo de filosofia. A idéia por trás do DRY é não só evitar duplicações de código, mas também múltiplas e divergentes maneiras de se realizar a mesma tarefa.

DRY também diz que cada pedaço do seu sistema de informação deve possuir uma representação única e inequívoca. Estou falando do seu banco de dados, seu esquema de testes, seu dispositivo de deploy e até mesmo da documentação do seu sistema.

Um projeto de software é muito mais do que o seu código. Você deve encontrar uma forma única de representar cada um dos recursos envolvidos na criação de seus projetos, caso contrário você terá de manter múltiplas representações diferentes de cada recurso, e no caso de uma mudança se prepare para ter muita dor de cabeça. E mudanças acontecem o tempo todo. Não se repetir é importante se desejar ser flexível quanto às alterações em seu sistema.

Quando estamos falamos apenas de código, a criação de uma biblioteca ou um módulo pode ser o suficiente para evitar repetições. Mas no que diz respeito ao banco de dados, por exemplo, talvez seja necessário uma outra abordagem como a criação de uma ferramenta geradora de código ou um sistema de automação, apenas para citar alguns exemplos.

Obviamente DRY não é infalível, em alguns casos o esforço para manter uma biblioteca única para todos os seus projetos, ou para evitar determinados tipos de duplicações em seus códigos pode ser muito maior do que o esforço necessário ao manter cópias diferentes do mesmo código.

“Don’t Repeat Yourself” – Ruby on Rails foi criado com este conceito em mente. Quase tudo que o fazemos no desenvolvimento de projetos com Rails visa evitar duplicações e repetições, mesmo quando falamos de banco de dados e testes. Por este motivo é que “não se repetir” se tornou o principal lema dos desenvolvedores Rails.