O Carlos Brando escreveu recentemente um post que me fez voltar a pensar nisso.

Geração de código é um assunto polêmico. Tem gente que acha que isso é tudo sobre produtividade e idolatra ferramentas que, praticamente, constroem aplicações inteiras; outros acreditam que está longe de ser uma boa prática de programação, que só traz dor de cabeça conforme o projeto evolui e algumas coisas precisam ser mudadas.

Mas eu não vim falar aqui que basta ter bom senso, que depente, ou que devemos pensar no meio termo. Eu sempre pensei e continuo pensando sobre esse tema, vim só relatar algumas conclusões.

Necessidade

Meu interesse pelo assunto surgiu quando comecei a trabalhar profissionalmente com Java, pouco antes de me formar. Eu ainda estava aprendendo a criar aplicações. Desenvolver em Java significava muito pra mim. Cresci ouvindo de todo mundo “Java é o futuro”. Embora eu conhecesse a linguagem e soubesse como programar orientado a objetos, eu ainda precisava aprender algumas frameworks além de entender vários padrões de projetos. Se não fosse assim, ou eu não conseguiria fazer o projeto a tempo, ou não estaria fazendo a coisa da “forma certa”. (Apesar de tudo, essas coisas me faziam bem, mas isso é assunto pra outro post)

O que isso tem a ver com geração de código? Tudo. Eu tinha muito código pra escrever por dia para conseguir fazer um simples CRUD. Tinham alguns arquivos de configuração tediosos com mais metadados que dados. Uma mudança aqui acarretava noutras tantas aculá. Então advinha a ideia que tive? Isso, gerar código.

Pontapé

Foi aí que nasceu o Pontapé, um gerador de código feito como trabalho de conclusão de curso. A ideia era que eu pudesse criar um modelo básico e ele gerasse código seguindo minhas convenções para começar o projeto, como POJOs, mapeamentos do Hibernate (na época era XML), configurações do Spring, etc.

Durante o trabalho, me peguei algumas vezes pensando até onde eu poderia ir gerando código. Mas sempre fui equilibrado e não exagerei na dose, o objetivo era ajudar nos primeiros passos, e depois abandonar o gerador. Fiz o gerador, ficou legal e apliquei em alguns projetos. No final dos estudos, já conhecendo um pouco do Rails, concluí que essa necessidade surgiu por conta de algumas limitações da linguagem que eu usava.

Rails

Assim como pra outras pessoas, o Ruby e o Rails vinheram pra quebrar alguns paradigmas que eu carregava: a linguagem altamente dinâmica permitia criar métodos em tempo de execução; a geração de código em disco era mínima; os models eram limpos e intuitivos. Enfim, era tudo isso que você já sabe.

Aí radicalizei! Imaginei que todo pedaço de código repetido no projeto deveria ser eliminado; que deveríamos ser DRY acima de tudo; e que geração de código devia ser feito em memória, nada em disco, no estilo ActiveScaffold. O que eu queria fazer era encontrar padrões de telas no meu sistema e criar formas dinâmicas de gerá-las – pensei que a tendência seria essa.

Simplicidade

Uma bom jeito de aprender a programar numa nova linguagem é conhecendo o código dos outros. Eu andei abrindo alguns projetos open source e observei que às vezes não devemos ser DRY, a geração em disco ou a duplicação de código pode ser importante para deixar o código mais acessível. Se tivermos vários plugins, helpers, métodos dinâmicos e todo o poder do Ruby sendo explorado ao máximo, o código pode ficar mais enxuto, entratando, menos intuitivo para os outros programadores. O scaffold do Rails, por exemplo, gera um código que todo mundo conhece.

Seja lá como for, manter a simplicidade é o nosso maior desafio.