Sim, ainda tem muita coisa a ser dita sobre DRY. Como eu disse no primeiro artigo sobre este assunto, “Don’t Repeat Yourself” não é apenas uma regra, conceito ou boa prática, é uma filosofia. Então vamos filosofar mais um pouco sobre isto…

Li há um tempo atrás no livro The Pragmatic Programmer que nós programadores estamos sempre em modo de manutenção. Isto é uma verdade já que raramente escrevemos código original. Se pararmos para pensar, um código só pode ser considerado novo por alguns minutos após termos lhe escrito pela primeira vez, pois poucos tempo depois você certamente terá de revisitá-lo e alterá-lo. Assim, chegamos a conclusão de que gastamos mais do nosso tempo dando manutenção em um código já criado, do que criando um código original.

Você cria um trecho de código, para alterá-lo logo em seguida. Cria mais um pouco de código e então precisa voltar e corrigir um bug encontrado. Escreve mais alguma coisa, e então perde algumas horas refazendo um código que lhe pareceu mau escrito (refactoring).

“Don’t Repeat Yourself” tem a pretensão de simplificar a manutenção de nossos projetos tornando-os flexíveis. Por isto é um conceito que deve ser levado muito a sério por qualquer programador que se preze, independente de qual linguagem esteja utilizando.

No caso do Ruby on Rails, embora isto também seja verdade para outras linguagens e frameworks, temos a nossa disposição milhares de gems e plugins que simplificam nossa vida, evitando a duplicação desnecessária de código e facilitando a manutenção do projeto. Também temos a liberdade de criar nossas próprias bibliotecas ou módulos de uma forma muito simples e rápida, afim de evitar repetições em nosso código.

Mas uma outra coisa que também é importante comentar quando falamos em DRY são as ferramentas geradoras de código. Quem trabalha com Rails já está acostumado a utilizar alguns scripts, como os famosos ./script/generate migration, ./script/generate scaffold ou se você utiliza o Rspec em seu projeto também deve usar o ./script/generate rspec_scaffold.

Estas ferramentas são ótimas e economizam muito do nosso tempo. Mas nem sempre os scripts existentes cobrirão todas as suas necessidades, então surgem algumas perguntas: Em que momento se torna prático gastar meu tempo construindo algo assim? Talvez seja necessário algumas horas ou até um dia inteiro para se construir um bom gerador de código, além do esforço necessário em manter o seu código e ensinar os outros programadores a utilizá-lo. Como decidir se o retorno deste investimento é o suficiente para justificar a criação de algo assim?

Falarei mais sobre isto no próximo artigo.