Grails não é bala de prata

Na minha opinião, Grails é uma das melhores coisas que poderiam ocorrer para a comunidade Java. Não tenho dúvidas com relação a isto, e por uma razão muitos simples: Grails é desenvolvimento web na plataforma Java como sempre deveria ter sido: simples, direto e intuitivo. Porém tenho um conselho para você: não espere milagres.

Minha experiência com aqueles que estão iniciando o aprendizado do framework é a de que 90% das pessoas se maravilham com a ferramenta não pelos três atributos que mencionei acima (simples, direto e intuitivo), mas sim devido a um certo deslumbramento com o scaffolding.

Gostaria de deixar claro algo para vocês que acreditam nos “poderes maravilhosos do scaffolding”: scaffold em inglês significa nada mais, nada menos que andaime, ou seja, é apenas um esqueleto em cima do qual você pode construir sua aplicação, e não a aplicação em si.

Acho que a melhor maneira de descrever o tamanho deste equivoco consiste em expor uma analogia. Suponhamos que um dia você contrate uma firma de engenharia para construir a sua casa. Como não entende nada de construção, ao menos inicialmente há alguma confiança na competência dos arquitetos, engenheiros e equipe de construção, correto? Agora, imagine que ao ver o resultado final, você fique maravilhado com a aparência de sua casa.

Em um segundo momento, você irá notar que há vários detalhes na construção que lhe são familiares em outras construções. As mesmas maçanetas, estilos de janelas, portas, cores. Neste segundo momento, você começa a perceber que na realidade, o arquiteto responsável pela obra não sabe o significado da palavra criatividade.

E então chega o terceiro momento: aquele no qual você se muda para esta casa. Passada a primeira semana, os problemas já começam a aparecer. As torneiras não funcionam tão bem, as paredes não parecem ser tão sólidas, e você simplesmente não sente segurança na construção. PUm belo dia você irá pregar um quadro na parede e na terceira martelada um buraco gigante surgirá em sua parede, expondo um andaime por trás da mesma como sua estrutura.

Soa exagerado? Pois vou lhes contar uma coisa: tenho visto diversos sistemas que são inteiramente baseados em scaffolding. O sujeito começa a aprender Grails, satisfaz-se em apenas criar as classes de domínio. Não haveria problema algum se estes sistemas fossem feitos visando o aprendizado. O problema é que muitos estão sendo vendidos. Ponha-se no lugar de quem está comprando estes sistemas.

É aí que o scaffolding começa a mostrar a sua face real: porque para fazer com que sua aplicação tenha algum diferencial, o mínimo que o desenvolvedor precisa saber é Groovy. Precisa compreender que o scaffolding na realidade só serve para adiantar algum trabalho. Trabalho este que, numa boa? Normalmente não passa de 15% (estou chutando o número) do trabalho total.

Pode alguém aprender Grails e depois aprender Groovy? Sim, pode. No entanto, em algum momento esta pessoa vai ter de APRENDER Groovy, e no mínimo saber o que significa MVC. E isto, acreditem, em diversos casos não tenho visto acontecer. Sendo assim, gostaria de acabar aqui com alguns mitos sobre Grails.

Grails não é um gerador de código: ele gera algum código para você, é verdade, mas em uma aplicação real, raras vezes este código chegará a 10, 15% do trabalho. Mesmo que chegue, será um código que, nestes casos, sofrerá diversas customizações, tornando-se ao final do processo algo completamente diferente (ou seja, não chegará a 5% do total)

Groovy não é supérfluo: sim, se você quiser desenvolver algo de valor REAL, conhecimento da linguagem é essencial. Saber descrever alguns atributos em suas classes de domínio e validações não é suficiente.

Grails não tornará fácil o desenvolvimento de aplicações: apesar de remover boa parte da burocracia presente na plataforma Java EE, desenvolver uma aplicação SEMPRE é um processo complicado, que requer atenção, bom projeto, disciplina e competência. Grails não é um framework para quem não sabe programar.

Conhecer a plataforma Java é obrigatório: pelo menos o conhecimento mínimo é necessário. Lembre-se: sua aplicação irá para um container JEE, executado em uma JVM. É possível saber apenas Groovy e não Java (a linguagem)? Claro! Porém Groovy é baseado em Java, e as classes básicas do framework PRECISAM ser conhecidas.

Resumindo: se você realmente acha que Grails irá tornar o desenvolvimento de aplicações algo fácil, não gaste seu tempo com Grails, mas sim aprendendo o que é desenvolvimento de sistemas.


Publicado

em

por

Tags:

Comentários

16 respostas para “Grails não é bala de prata”

  1. Avatar de William Antônio Siqueira

    Oi,

    Interessante que o que você falou é uma grande verdade. Mexi com Grails para teste acreditando no que lia em blogs da vida. Percebi o que você disse!
    Hoje ainda não comecei a realizar meus projetos em Grails, mas sei que devo estudar seriamente a teoria antes de cair no “create-app” sem uma boa base.
    Mas mantenho minha “turminha imbatível que apronta confusões da pesada com uma aplicação que é pra lá de séria”: Hibernate, Struts…

    []’s

  2. Avatar de Wilson
    Wilson

    “Grails é desenvolvimento web na plataforma Java como sempre deveria ter sido”
    Acho que existem niveis de sistemas web desenvolvidos em java e onde acho que java é imbativel é no enterprise: companhias telefônicas, instituições financeiras, tive que sujar minhas mãos com rails uma vez e percebi que não, não tem capacidade de um aplicativo web a nivel enterprise, grails se seguir a mesma filosofia do rails vai estar fardado a ficar no mesmo nivel: para pequenos sites com pouco acesso e onde segurança e solidez não sejam requisitos primários. Você pode citar algum exemplo de um sistema grails sendo atualmente utilizado para gerenciar por exemplo uma empresa financeira com milhões de clientes espalhados pelo mundo? Segurança nas transações, multilinguagem/localização, multithread, estabilidade etc?

    1. Avatar de admin
      admin

      Ai que tá o que é realmente bacana Wilson: Grails gera pra você uma aplicação JEE exatamente como fariamos usando JSP puro ou qualquer outro framework. A diferença é que estamos usando Groovy e uma série de DSLs que agilizam bem este processo.

      Grails é na realidade uma mescla das duas filosofias: a da JEE com a qual estamos acostumados E a do Ruby on Rails, ou seja, une o melhor dois dois mundos.

      Neste ponto, de acordo com a minha experiência até agora, Grails coloca RoR no chinelo.

  3. Avatar de Wanderson Santos
    Wanderson Santos

    Bom post! Gostaria de enriquecer, compartilhando minha visão sobre os tópicos. ;-)

    * Scaffolding caiu do céu pra iniciar o sistema pelo que interessa (casos de uso complexos) e não pelos cadastros. Mas os cadastros precisam ser construídos depois. Quem “vende” Grails de outra forma convence pelos motivos errados.

    * O bacana do Groovy é que um desenvolvedor Java pode programar com sua sintaxe conhecida e conhecendo as vantagens da nova linguagem fazendo. “Make It Work, Then Make It Right”. É uma vantagem considerável em relação a Python ou Ruby pra equipes Java.

    * Grails facilita muito o desenvolvimento das aplicações, tanto pra novatos quanto experientes. Alguém que sai da faculdade pode fazer um sistema não só mais rápido, mas com melhor qualidade do que PHP ou JavaEE sem conhecer profundamente. Já estudar e dedicar pra fazer melhor no futuro faz diferença em qualquer linguagem ou plataforma.

    * Pra colocar uma primeira versão no ar, o desenvolvedor – além do Groovy/Grails – só precisa saber o básico da Plataforma Java: tipos, coleções, jvm. Também só o básico do Jetty pra subir pra produção. Dai pra frente a pessoa aprende fazendo. Este é um grande trunfo com relação a .NET, Java e até PHP. Venho observando cada dia mais que o muito aprofundar na teoria antes da prática não é garantia de bons sistemas.

    Full-stack frameworks tem sido a grande resposta para o “long tail” da nossa área (pequenas e média empresas) – algo que era dominado por VB, Access e FoxPro. E pra quem já tem conhecimento Java, é a melhor coisa que poderia ter acontecido, como foi bem frisado no post.

    Pra quem está interessado em .NET e Java mas flerta com Rails ou Django, Grails tem sido o melhor dos dois mundos: uma boa linguagem com boas ferramentas em uma boa plataforma.

    Bom trabalho a todos! :-)

  4. Avatar de Wanderson Santos
    Wanderson Santos

    Fiz um extenso comentário aqui, dai o sistema de comentário fez o favor de emitir um erro PHP! Se tiver tempo e paciência posto novamente…

    De qualquer forma, excelente post. Só achei que o título não está tão bem relacionado com o conteúdo. ;-)

    Com relação ao conteúdo, parece que o Grails é mais burocrático do que realmente é. A vantagem dele é que os desenvolvedores podem aprender fazendo, com menos risco de fazerem gambiarras como em PHP por exemplo. Um “Make It Work, Then Make It Right” mais seguro.

    Estudar e aprofundar é um ganho e necessidade em qualquer tecnologia. A vantagem de uma full-stack framework é eliminar a barreira inicial, e isso o Grails faz com méritos.

    Bom trabalho a todos!

  5. Avatar de Lucas

    Um sério risco oferecido por frameworks menos burocráticos, tipo Grails ou Rails, é o efeito “relaxado” causado em alguns programadores desleixados …

    1. Avatar de admin
      admin

      Concordo 100% com você Lucas. Aliás, este é o problema com diversas pessoas, que confundem liberdade com desleixo.

    2. Avatar de Heaven
      Heaven

      Depende, depende que de como é esse menos burocratico, por exemplo o framework Spaghetti (framework php muito bom por sinal) ele é menos burocratico em critérios de configurações, no máximo você define apenas qual é o banco de dados usado, entretanto o mesmo sendo muito fácil a ponto de nem necessitar de scarfolding para isso (o que acho ótimo, já que nem tem scafolding ainda) é bastante restrito quanto a sua forma de trabalhar, o modelo deve ser assim, o controller deve ser assado, nós destestamos gambiarras, entre outras coisas.

      No caso quando se usa um framework restrito quanto a forma de trabalhar, normalmente obriga o desenvolvedor a conhecer bem o código deste framework para saber como o mesmo trabalha e como poderá criar seus próprios componentes ou mesmo melhorias, além que obriga o desenvolvedor também a conhecer bem o medelo de código que fora construído além dos padrões que o mesmo trabalha, no caso do spaghetti passei um bom tempo lendo o forum e o manual do mesmo para depois ver que o manual realmente era o código e a idéia do framework, no final das contas me abriu os olhos a escolher técnicas e bibliotecas para criar coisas parecidas para superar as limitações que estava tendo, mas a idéia de nem necessitar de uma única linha de sql foi a melhor de todas.

  6. Avatar de Francisco
    Francisco

    Excelente texto e opinião do Lucas também foi muito bem colocada.
    Trabalho com JAVA a muito tempo e vejo realmente muitas atrocidades quando alguns falam em morte do java pelo Grails, ou quando juntam tudo Grails, Rails, Groovy/Grails.
    Estou me posicionando, lendo e testando os conhecimentos que ando lendo. Parabens e tenho lido e acompanhado sues tutoriais e dicas.

  7. Avatar de Andre Fonseca

    Uma das coisa que mais me assustam nesses tópicos é quando vejo pessoas falando de Groovy como fosse algo totalmente desconexo de java. Groovy foi feito e de certa forma é Java. Saber Java, ajuda muito a escrever bons códigos em Groovy e por consequencia fazer uma boa aplicação em Grails.
    vocês podem até não concordar, mas para mim, vejo o Grails como framework web de Groovy/Java, onde existem opções quase tão boas quanto : VRaptor, Mentawai, struts 2.0, etc.
    Bem essa é minha opnião.

  8. Avatar de Adriano Aquino

    Concordo.

    Para quem já conhece a arquitetura JAVA e está familiarizado com MVC, é uma mão na roda, pois com alguma personalização nos templates que são utilizados para geração dos controller/jsp e afins, agiliza em muito o desenvolvimento, depois é necessário adicionar alguns recursos para contemplar o que um sistema de verdade merece, estou mexendo a uma semana com grails (caiu do céu os artigos na JM 75~79) e já fiz muita coisa interessante nestes 7 dias, vejo potencial para backend, para front, tenho dúvidas, terei que trabalhar num projeto para ver o resultado. Estou investindo um bom tempo em grails, pois acredito que quando os GPS, Donos de Empresas de TI perceberem como as coisas são mais rápidas com este tipo de tecnologia, teremos mudança no mercado, mas mesmo assim, parte do projeto será java java, sé é que me entendem.

    Outra coisa, sobre os 10/15%, acredito que depende muito do projeto, já trabalhei em projeto que 70% era apenas CRUDS que com grails iria ter gasto, acredito eu, menos da metade do tempo foi gasto.

    1. Avatar de admin
      admin

      Oi Adriano: concordo, cada caso é único (e eu curto incluir alguns elementos dramáticos no meu texto) =)

      Que bacana que os meus artigos te foram úteis! Neste blog costumo publicar algum material também. Espero que possa lhe ajudar no que precisar!

      1. Avatar de Luiz
        Luiz

        Esse negócio de “Incluir elementos dramáticos no texto” é meio ruim pois tira a credibilidade da sua informação.

        De qualquer maneira, obrigado pelo feedback =)

        1. Avatar de Kico (Henrique Lobo Weissmann)
          Kico (Henrique Lobo Weissmann)

          Opa, valeu pelo toque Luiz, mas neste ponto ai não vou mudar não :)

  9. Avatar de Thiago Marinho

    Olá! Antes de chegar aqui estive no GUJ lendo o comentário do pessoal sobre o problema script/generate (scaffold) ou andaime!

    Foi muito bom ler esse post bem como o comentário dos colegas!

    Estou iniciando em Grails através de um projeto de código aberto, espero aprender a utilizar bem esse framework!

    O pré-requisito eu já tenho, hehe! a saber: padrão MVC e Java Web =)

    abraços t+

    ah, obrigado pelo grailsbrasil estou utilizando muito!! =)

    @tgmarinho

    1. Avatar de admin
      admin

      Oi Thiago. Que bom que tenha gostado do Grails Brasil. Valeu pelo apoio!

Deixe uma resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.