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.