Generator e como a preguiça ajuda a construir softwares melhores

Preguiça é normalmente vista de maneira pejorativa, como fazer alguma coisa mal feita, da maneira mais fácil para se livrar do problema, ou muitas das vezes, nem fazer. Mas preguiça, e em desenvolvimento de softwares, não é sempre ruim. A preguiça “boa” pode ser benéfica para o desenvolvimento de softwares.

Um exemplo disso é um software gerador de códigos, que no meu caso, foi utilizado para gerar o esqueleto de uma aplicação em Flex e ColdFusion.

Preguiça

Há o programador preguiçoso imediatista, que realiza determinada tarefa da maneira mais fácil e cômoda no momento, sem que ele tenha que realizar um grande esforço de pesquisa ou aprendizado de algo. Utilizando os subsídios que ele tem, mesmo que não sejam suficientes, ele até irá resolver o problema, mas não será a abordagem mais efetiva e muito possível trará dores de cabeça futuras, como problemas de compatibilidade, padronização e performance.

Contudo, a preguiça ainda pode ser benéfica. Há muitos bons programadores preguiçosos, e seu tipo de preguiça é diferente: como uma “preguiça a longo prazo”.

“Preguiça é uma das virtudes fundamentais da programação, junto com impaciência e hubris. Preguiça para nunca resolver manualmente o que pode ser resolvido de forma automática.” — Ronaldo Ferraz no ReflectiveSurface

Quantos vezes já não vi um programador escrever um programa para resolver um problema do que resolver o problema “manualmente”? Embora no primeiro momento ele tenha de pensar, gastar energia e eventualmente fazer alguma pesquisa e quebrar a cabeça, ele fica orgulhoso do resultado. E mais ainda se o seu programa puder ser reutilizado.

Eu tenho um pensamento de quanto menos efetivamente programa-se um software, melhor ele será. Considero preferível utilizar mais tempo analisando os requerimentos do software e arquitetando-o, de modo que o problema que o software se propõe a resolver seja realmente solucionado, do que programar e mudar, programar e mudar, programar e mudar, e sair literamente no prejuízo, estourando as horas de desenvolvimento.

Há um text interessante sobre bons programadores e sua preguiça no blog Google Blogscoped.

Generator

Nos últimos 3-4 meses tenho participado de desenvolvimento de softwares utilizando o Macromedia Flex e o framework Cairngorm (que pretendo escrever no futuro). Especificamente o primeiro deles era (e está em fase final de desenvolvimento) relativamente complexo, contemplando uma série de processos de uma empresa. Desse modo, uma grande quantidade de telas e tabelas no banco de dados era fatal.

O Flex se propõe a resolver um problema de experiência e uso do software, lidando com a interface, e esse deveria ser o foco da equipe, uma vez que os processos já estavam todos definidos. Assim, a equipe ficaria livre para se preocupar com a interface do sistema ao invés de programações burocráticas e maçantes, como o CRUD (componentes de Create, Retrieve, Update e Delete para comunicação com o banco de dados) e classes relativas ao framework em Flex, como VOs, Services e Commands.

Aqui foi quando a (minha) “preguiça” entrou em ação e desenvolvi um software, escrito em ColdFusion, que por falta de nome mais original, ficou o descritivo nome de Generator.

O Generator gera aplicações em Flex e ColdFusion a partir do banco de dados (como no Ruby on Rails), deixando mais tempo disponível para a equipe se preocupar com a interface e a usabilidade, que é o que realmente foi vendido e interessa para o cliente e para o projeto em si. Eu não considero a geração de aplicações unicamente partir do banco de dados o modelo ideal, mas foi uma abordagem interessante que poupou muito tempo de desenvolvimento, e muito produtiva para a primeira vez de geração de muitas das partes de um grande software. A redução de bugs também é grande. Digita-se menos e há menos espaço para a preguiça “ruim”. Quantos desenvolvedores não deixam a tag cfqueryparam para “depois”?

Não é o único software do gênero, claro. O Eclipse já faz isso há muito tempo para programas Java. Em termos de ColdFusion, na lista CFCDev, por exemplo, é freqüente a dicussão e sugestão de softwares geradores de código. Construi o Generator pois e necessidade era maior do que gerar CFCs ou Beans, e sim customizar e gerar outros componentes e classes, inclusive em Flex e ActionScript.

Funcionamento

O Generator utiliza um conector para o banco de dados, então é bem fácil de portá-lo para outros bancos de dados. Atualmente há dois conectores desenvolvidos (por mim e pelo DBA da equipe, Rubens Albuquerque), para PostgreSQL e Oracle.

Escolhe-se uma database dentro as disponíveis no banco conectado, e as tabelas são listadas, com a opção de geração invidual dos componentes.

Dentro os componentes do ColdFusion, é possível gerar o Facade, Managers e a camada de acesso a dados, com seus elementos de CRUD; nesse caso as funções de Select, Insert, Update e Delete das tabelas de banco de dados, que leêm as Sequences (no caso do Postgre e Oracle) quando necessário. Cuida também das validações (cfargument, cfqueryparam, etc) e formatações necessárias em números, datas, campos nulos, etc. e inclusive detecta o relacionamento entre as tabelas e trata-os devidamente nos Managers. Por exemplo, para incluir um “Registro de Contato”, que é uma “Transação” do sistema, primeira adiciona-se uma “Transação”, e depois o “Registro de Contato”, que contém um campo chave para a “Transação”.

Referente ao Flex, os componentes do Cairngorm gerados são: Delegate, Controller, Commands, VOs, Model e Services, restando o ViewHelper e a tela propriamente dita. É um ganho muito grande para a equipe de desenvolvimento.

Evidente que o Generator não desenvolveu o software sozinho, e a equipe teve utilizar algum tempo trabalhando nos componentes gerados automaticamente. Um exemplo clássico foram os SELECTs. O software em que trabalhávamos demandava SELECTs complexos, com joins, sub-selects e afins, que o Generator não saberia tratar; ou ainda, funções de envio e e recebimento de e-mails (triviais e rápidas de desenvolver). Como ele era baseado no banco de dados, não em use-cases, alguns Commands tiverem de ser desenvolvidos manualmente.

Conclusão

Ainda assim com algumas modificações e adições necessárias manualmente pela equipe, o tempo economizado, principalmente com o CRUD, foi muito grande. É uma ferramenta que será melhorada e customizada com o decorrer do tempo e experiências enfrentadas.

A interpretação de use cases a partir de arquivox XMI (XML exportado de muitos softwares de UML) é um dos próximos passos do Generator. Com o conceito e a leitura do banco de dados é possível até mesmo gerar outros componentes, como Beans, TransferObjects e afins, conforme a necessidade.

É possível até mesmo construir telas! Sejam estas “padronizadas”, como por exemplo, cadastros básicos (cidades, categorias, tipos e afins), ou telas mais elaborados com interfaces igualmente padronizadas. Por exemplo: um formulário de busca em cima, onde os campos que são chaves estrangeiras são combo-box (e como o sistema sabe com quem ela é chave, pode gerar o Combobox e chamar uma função remota para popula-lo) e um datagrid em baixo, clicável, que leva para o formulário de edição daquele ítem. Até mesmo o formulário, que não é “padrão” pode ser gerado, já que é conhecido o tipo de dados (por exemplo, varchar até 100 é input de texto, varchar com mais de 100 é text area, etc). Restando após, a integração com o visual designer para o look and feel da interface do sistema. Mas esses recursos com certeza vão ficar mais para frente. 🙂