Há alguns dias entregamos a primeira fase de um Projeto desenvolvido utilizando o Spring Roo. Nesse post vou compartilhar essa experiência.
O Projeto
Primeiro detalhe, só pra variar, o tempo bem escasso. A idéia era disponibilizar o sistema funcionando em 2 semanas. As funcionalidades eram bem simples, alguns CRUDS, um deles um pouco maior com alguns relacionamentos e validações mais chatas, várias opções de pesquisa/filtros e relatórios.
A equipe
Nesse projeto era bem pequena, 2 desenvolvedores.Porquê o Spring Roo?
Meu primeiro contato com o Roo foi no TDC2009, na palestra do Rod Johnson e logo depois com o Renato Bellia no Casual Class sobre Spring Plataform.
Finalmente chegamos a tão desejada "alta-produtividade" no desenvolvimento Java corporativo! Será? Penso que produtividade vai bem além de uma ferramenta e/ou metodologia, são vários os fatores que influenciam, mas não quero falar sobre isso aqui.
Imparcial e sem falsas ilusões fiquei bem curioso pela simplicidade com que o Roo trata as tarefas burocráticas na infra-estrutura de um projeto Java, que sempre foi alvo de muitas críticas. Outro ponto que chamou minha atenção foi a possibilidade de, caso fosse conveniente, desligar o Roo e continuar trabalhando e evoluindo o sistema.Além das funcionalidades da ferramenta, o fator decisivo na escolha do Spring Roo foi a arquitetura/estrutura gerada por ele com: Spring MVC, JPA/Hibernate, Spring Security. Tecnologias aderente a linha adotada em outros projetos na empresa. O Roo entrou em cena com o papel de propulsor.
Desenvolvimento
No início do projeto a versão disponível do Spring Roo era 1.1.0.M1. De lá pra cá várias melhorias foram feitas até a 1.1.0 GA. Naquele momento o plugin do GWT do Roo estava bem imaturo, ainda em processo de desenvolvimento e, então, pra evitar o risco não usamos. A estratégia na camada view foi seguir uma linha mais clássica Java para Web, desenvolvimento com JSP e Custom Tags do Spring Web, e claro com Spring MVC 3.0.
Ainda sobre a camada view, outra feature que ainda não existia no Roo era o suporte nativo a JSON para REST, adotado na atual versão. Resolvemos o JSON sem stress, usando algumas funcionalidades do Spring MVC 3. O Ajax no front-end foi resolvido com framework JavaScript Dojo, adotado pelos componentes do Spring Web para algumas perfumárias. O Dojo deixou a desejar, enfrentamos alguns problemas de compatibilidade do JS com IE, por isso em alguns pontos usamos o JQuery, que sem dúvida alguma é o meu prefererido!
A curva de aprendizado do Roo é bem curta, em poucas horas definimos todo modelo de entidades, as Controllers, pesquisas e o esqueleto das Views, tudo pelo shell. Usamos o STS tornando a integração do shell com IDE bem transparente, além de contar com todas peculiaridades para os produtos Spring.
Conclusão
O principal objetivo: entregar o projeto atendendo a expectativa do cliente no prazo esperado, foi alcançado!
O Roo realmente acelera o desenvolvimento, resolve muitas picuinhas chatas e o melhor de tudo: gera código bom, fácil de compreender e avançar, com todo aparato de testes, uma arquitetura enxuta e consistente. Conhecer um pouco sobre AOP, ou melhor AspectJ, pode facilita a compreensão do que está rolando por trás da cortina.
Dois pontos que merecem uma maior atenção seriam o cuidado com relacionamentos mais avançados entre entidades (Scaffold) e a organização das buscas. Vou descrever mais detalhes disso em outro post.
Gostei bastante do Roo, pretendendo continuar usando em projetos com características diferentes, maiores e mais complexos.
Documentação do Roo.
Posts sobre o Roo aqui no Globalcoders.
Um pouco mais da minha experiência com o Roo.
[]s
Eder Magalhães
www.yaw.com.br
twitter.com/youandwe
twitter.com/edermag
Comentários