Amigos,

Este é meu primeiro post no fórum, e espero que eu possa contribuir com as discussões com os colegas.

Gostaria de compartilhar com vocês uma experiência de trabalho que estou passando atualmente, e pedir algumas opiniões de pessoas mais experimentadas do que eu.

Já há algum ano, tenho trabalho em um projeto utilizando Grails. É a minha primeira experiência em uma empresa com essa framework (trabalho há anos com Java e .NET), e conhecia o Grails apenas por estudar, com tutoriais e livros, etc. Esse é o meu primeiro projeto "de verdade" com o Grails. Minha impressão do framework sempre foi muito boa e se confirmou; de fato, uma excelente ferramenta. Tem seus probleminhas, como todas as outras, mas não deixa de ser nada menos do que excelente, na minha visão.

Porém, o Grails não é capaz de resolver tudo.

Nossa equipe desenvolveu um código, na minha opinião, com diversos problemas de design e más práticas, acreditando que estamos desenvolvendo no "Grails way". Minha impressão é que meus colegas imaginam que, com o Grails e o Groovy, nosso código será automaticamente lindo e fantástico, e que não precisamos nos esforçar muito pra isso. Alguns exemplos:

- uso excessivo de CommandObjects nos controllers. Temos praticamente um Command para cada Domain...

- lógica de negócio dentro de controllers. Inclusive com o uso de coisas assim

class AlgumController {
	def action() {
		...
		ClasseDomain.withTransaction {
			//mais logica de negocio
		}
	}
}

A justificativa da equipe é que "no Grails não precisamos de um monte de classes como no Java, é tudo mais fácil"...

- classes de serviço com SQL nativo. Sim, dentro do proprio Service. Novamente, a justificativa é que "no Grails dá pra fazer tudo aqui mesmo, não precisamos de um monte de coisas como no Java".

- Também há "services" que acessam responsabilidades não necessariamente acopladas à regra de negócio. Exemplo: temos aqui um service que precisa acessar um WS SOAP externo, e converter o retorno desse ws em uma classe de domínio. A requisicao http, a configuração do xml de envio (soap:Envelope, soap:Body, etc), é tudo feito dentro do próprio service. E o posterior parse da resposta também. O que os meus colegas vêem como "facilidades" do Grails, a meu ver é uma violação inaceitável da coesão dessa classe. Sem falar que se amanhã esse WS externo mudar, a manutenção seria feita na camada de negócio, que não tem nada a ver com isso (existem vários services nessa situação que relatei)

- lógica excessiva dentro dos gsps. Agrupamento e sort de coleções dentro da página, invocação de métodos de forma excessiva, muitos cálculos. Não me oponho totalmente a isso, mas penso que lógica com granularidade maior poderia ser feita no controller e o resultado enviado para a página. E o caso aqui é o contrário, o "grosso" do trabalho está sendo feito dentro do gsp. Não concordo com essa abordagem.

- muitos, muitos MESMO métodos utilizando HQL nas classes de dominio que são expostos por métodos estáticos. A princípio não vi muito problema, mas saiu do controle; há classes aqui com dezenas desses métodos. Não está legal um monte de HQL nas classes de domínio, mas todo dia aparece um novo...

- como podem imaginar, não temos um único teste, nem unitário, nem de integração, nada. E quando bato nessa tecla, meus colegas dizem preferir fazer o codigo e testar no browser, já que "é mais rápido porque não precisa ficar reiniciando o servidor, é só fazer, testar, corrigir, atualizar o browser, e testar de novo, Grails é demais!"...

- vejam esse exemplo:

def variavel = Domain.findByAlgo("parametro").prop

Esse codigo estava lancando um NullPointer, pois o find não estava encontrando nada. Ok. Vejam a "solução":

def variavel = Domain.findByAlgo("parametro")?.prop

O NullPointer foi resolvido, com direito ao colega dizer "viva o Grails!" (na verdade o safe navigation aí é do Groovy...). Como podem imaginar, essa linha funcionou e a "variavel" ficou nula...o que gerou um NullPointer NA LINHA DE CODIGO SEGUINTE!

Vendo essas coisas, me vem à mente aquela frase:

"Pra quem tem um martelo, qualquer problema é um prego."

Eu vejo valor no Grails. Mas ele não programa pra nós, ele não faz nada sozinho. Meus colegas parecem pensar o contrário, que ao usar o Grails "nosso projeto é muito melhor que se estivessemos usando Java", o que está nos levando a um código de pésssima qualidade.

Por favor, amigos, gostaria de sugestões e opiniões de como posso reverter esse cenário e tentar convencer meus colegas de trabalho, para usarmos de forma eficiente os ótimos recursos do Grails.

Obrigado.