Grails - a "esperança estilhaçada"
24/07/2013 14:24
-1
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.
Tags: boas-praticas


0
"Grandes poderes requerem grandes responsabilidades" - Tio do homem Aranha.

Cara, o problema pelo que você relatou nesse desabafo não é necessariamente com o Grails e a flexibilidade que ele te dá, e sim as péssimas práticas adotadas por essa equipe. "Gambiarra" dá para fazer com qualquer linguagem e framework.

O Grails é "menos burocrático", mas isso pode se tornar um belo tiro no pé dependendo de quem o conduz, como você mesmo descreveu. Infelizmente acredito que isso irá continuar seja com essa tecnologia, ou com outra adotada... afinal o problema e técnico (Formação profissional).

Tente ensiná-los boas práticas, e boa sorte!
24/07/2013 15:04


0
Concordo com o luciano inclusive o problema do NullPointerException não despensa a validação dos dados esperados ou uso de exceções, ou algum tipo de teste a exemplo de outras linguagens dinâmicas que também tem o mesmo recurso.
24/07/2013 15:34


1
Oi Tiago,

este na realidade é um problema da sua equipe: curiosamente, eu já vi a mesma coisa se repetindo mais de uma vez em consultorias que presto por aí.

O argumento "vou colocar a lógica de negócio aqui no controlador por que com Grails a coisa é muito mais simples", por exemplo, é um dos mais furados de todos os universos paralelos. Idem pode se dizer de qualquer framework, seja ele Java ou não: Play por exemplo.

De nada adianta você ter a ferramenta mais foda do Cosmos se sua equipe joga contra você, tal como tá exposto no seu post. O título então "esperança estilhaçada" diz muito de um erro seu: o de acreditar que mudando o framework o pessoal trabalharia direito. Idem ocorreria no Play, Ruby on Rails ou qualquer outro framework de mesma linha do Grails pelo que você tá falando. E exatamente por soar sensacionalista negativei.

Minha sugestão pra você é a seguinte: mostre pra sua equipe como usar a coisa corretamente.

* Command objects: sempre devem ser raros. Eles surgem pra situações nas quais é necessária uma validação que vá além da sua classe de domínio.

* Lógica de negócio no controlador: um Entidade.findAll() até se justifica. Mais do que isto, é início de gelada. O ideal de ter as coisas no serviço também é que assim as coisas se tornam mais fáceis de serem testadas.

E de fato: no Grails você não precisa de uma infinidade de classes como no Java, mas isto não quer dizer que as "poucas" que você possua devam ser usadas porcamente. Eu diria isto pra sua equipe.

E o mais importante de tudo: não culpe a ferramenta, mas às pessoas. Estes mesmíssimos problemas que você enfrenta, me repetindo, surgiriam em qualquer framework/ambiente de desenvolvimento.

Sabe o que eu faria na sua situação? Reuniria a equipe e começaria um mea culpa coletivo. Converse com todo mundo e, especialmente, deixe tudo mundo se expressar também. Colete os comentários de cada membro da equipe (não ignore ninguém) e especialmente os que a equipe faz a seu respeito. Bata sua visão inicial com a que obtiver nesta reunião e comece a divulgar boas práticas dentro da equipe de uma forma saudável. Funciona em 99% dos casos. :)


1
Oi pessoal,

Obrigado pelos comentários. Eu concordo muito com esses argumentos. Na verdade, como eu tentei colocar, não penso que a "culpa" é da ferramenta, pelo contrário. Nós que não estamos sabendo utilizar os recursos que o framework nos fornece.

Por outro lado, muitos dos colegas aqui pensam que, sim, estão sim! Afinal de contas, nós usamos Grails e o que poderia dar errado?...É esse pensamento que estou tentando rebater internamente. Penso que é algo sobre o qual o próprio Kico já escreveu, o tal do "hype", de pensar que, só porque usamos uma excelente ferramenta, tudo já vai ficar "nos conformes". E nós sabemos que não é assim...

Kico, talvez eu tenha me excedido no título do post, hehe, perdoe o "sensacionalismo" pois não era minha intenção. Mas "esperança estilhaçada", com o perdão do exagero, reflete bem o que eu pessoalmente pensava quando entrei neste trabalho, de que seria "mais fácil" aplicar boas práticas com o Groovy/Grails, fazer um código mais legível, elegante, orientado ao domínio, DDD, etc, etc...e não é assim que está sendo. E, caso o meu post tenha soado assim, eu nenhum momento eu quero me eximir pois também faço parte da mesma equipe e estou no mesmo barco. Minha falta de insistência em propor melhores práticas já está sendo um erro (aliás, não sou o "líder" nem o arquiteto nem nada, mas temos um aqui, que deveria ser o nosso "especialista em Grails"...)

Perdoem o "desabafo", e vou refletir muito sobre as sugestões.

Obrigado.

ps: "A Esperança Estilhaçada" também é o título de um livro do Augusto Nunes (nada a ver com software) :)
24/07/2013 18:19


0
Olá Tiago!!

Como o Kico, colocou o seu problema não é o framework e sim a equipe, já passei por isso, e no meu caso, quando ficou insustentável trabalhar como uma equipe nada flexível, acabei optando por procurar algo mais condizente com o que eu estava procurando.

A minha solução foi sair da empresa onde eu trabalhava, encontrei outra onde estou contente, pois a equipe é muito mais flexível, mesmo assim demorou algum tempo (7 meses) para que as coisas começassem a mudar. Eu tive que ir provando aos poucos o porquê da mudança e como uma melhor prática de programação ajuda no dia a dia.

Vendo o exemplo que você demonstrou do safe navigation, acredito que não estão utilizando os testes, ou não como deveriam.

No início a utilização dos testes soa como uma perca de tempo, comece por você fazendo estes testes e provando o tempo que você economiza e a eficiência do seu código.

Último conselho, tenha muita paciência pois uma mentalidade não se muda de uma hora pra outra, muito menos sem apoio da direção da empresa.








0
Sim, Leandro, eu concordo contigo e entendo que esse tipo de mudança exige uma nova postura da equipe, e isso não acontece da noite pro dia. Leva tempo, e é difícil, mas acredito que o principal fator motivador deve ser perceber a necessidade da mudança, de fazer as coisas de forma diferente. Esse é o nosso entrave, a meu ver, já que minha impressão é que a equipe está muito satisfeita com o código do jeito que está...

E não, não utilizamos testes. Há alguns poucos que escrevi, mas o código da aplicação mudou e os testes não foram modificados, o que levou a quebra dos mesmos. Resultado, rodamos o build sem testes, sem confiança na entrega, e testamos MANUALMENTE a aplicação...péssimo. A equipe realmente não tem experiência nenhuma com testes, TDD, etc, mas a meu ver esse problema é o de menos; Junit e TDD se aprendem e se aperfeiçoam com o tempo. O que tem me incomodado é a postura de "Grails é lindo e tudo isso que voce está dizendo é pra encher o saco"...tá difícil :(

Como eu disse antes não estou me eximindo de nada. Talvez se eu tivesse sido mais incisivo e convincente com os colegas não estaríamos hoje nessa situação, não deixa de ser uma falha grave da minha parte (aliás, como podem imaginar, estamos frequentemente fazendo horas extras, trabalhando aos sabados, domingos...). Mas acredito na mudança, ainda (espero!)

Obrigado.
24/07/2013 23:32



Ainda não faz parte da comunidade???

Para se registrar, clique aqui.


Aprenda Groovy e Grails com a Formação itexto!

Newsletter Semana Groovy

Assinar

Envie seu link!


Livro de Grails


/dev/All

Os melhores blogs de TI (e em português) em um único lugar!

 
Creative Commons
RSS Grails Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.
Ver: 4.14.0
itexto