Viciados em scaffolding

[kicolobo]

Algo que tem me preocupado ultimamente consiste no fato de certos “desenvolvedores” acreditarem que frameworks como Grails e RoR tornam o desenvolvimento de sistemas algo fácil devido a um certo deslumbramento com o scaffolding.

Tenho visto diversos casos de sistemas sendo vendidos que nada mais são do que um amontoado de código gerado por scaffold destes frameworks. Como resultado, é claro: o filme de toda a nossa categoria é queimado.

Publiquei no meu blog os meus pensamentos a respeito, no caso, focando em Grails, e gostaria de saber a opinião de vocês a respeito:

Grails não é bala de prata - /dev/Kico

[luizrobertofreitas]

Acredito que como qualquer recurso, scaffolding deve ser utilizado com propósitos bem definidos, ou seja, que ele não seja gerado e definitivo numa aplicação.

[ViniGodoy]

É, Kiko. Essa conversa vem desde que o Delphi propos o conceito de RAD. Na verdade, talvez venha de antes também. Os nomes do “faça-fácil” só mudam, e sempre existem os desenvolvedores empolgados demais com a tecnologia, e esperando milagres.

Lembro-me que uma vez vi um sistema inteirinho desenvolvido usando o RAD. Era um inferno dar manutenção naquilo, mesmo que o Delphi apresentasse conceitos bastante sólidos. Coisas aconteciam magicamente e até um desenvolvedor novo mapear todos os atributos que foram definidos em campinhos espalhados pelas dezenas de formulários da aplicação, já se foram os prazos.

Como tudo na informática, abre-se mão da flexibilidade em prol da produtividade. Entretanto, quanto menos flexível você se torna, mais limitado também é o escopo da sua solução. Se você usa scaffolding demais, vai estar limitado apenas ao que os projetistas do grails imaginaram que é um sistema “default”. Se você mesmo se amarrar nesse código, terá um sistema de difícil manutenção e adaptação, embora efetivamente o tenha construído em tempo recorde.

[kicolobo]

[quote=ViniGodoy]É, Kiko. Essa conversa vem desde que o Delphi propos o conceito de RAD. Na verdade, talvez venha de antes também. Os nomes do “faça-fácil” só mudam, e sempre existem os desenvolvedores empolgados demais com a tecnologia, e esperando milagres.

Lembro-me que uma vez vi um sistema inteirinho desenvolvido usando o RAD. Era um inferno dar manutenção naquilo, mesmo que o Delphi apresentasse conceitos bastante sólidos. Coisas aconteciam magicamente e até um desenvolvedor novo mapear todos os atributos que foram definidos em campinhos espalhados pelas dezenas de formulários da aplicação, já se foram os prazos.

Como tudo na informática, abre-se mão da flexibilidade em prol da produtividade. Entretanto, quanto menos flexível você se torna, mais limitado também é o escopo da sua solução. Se você usa scaffolding demais, vai estar limitado apenas ao que os projetistas do grails imaginaram que é um sistema “default”. Se você mesmo se amarrar nesse código, terá um sistema de difícil manutenção e adaptação, embora efetivamente o tenha construído em tempo recorde.
[/quote]

Velha é o apelido desta história

Mas o que REALMENTE me chocou foram algumas das perguntas que venho recebendo no meu e-mail. Há poucos dias atrás, um sujeito que está terminando o seu TCC sobre Grails me veio com as seguintes perguntas:

• Aonde fica a classe String?
• Aonde eu altero a visualização das minhas páginas?
• O que é um controlador?

E ai eu fico pensando: putz, como alguém que está formando, executando um trabalho de conclusão de curso pode não saber ABSOLUTAMENTE nada sobre o próprio assunto? É quando cai a ficha do porquê da escolha de RoR ou Grails por este tipo de “profissional”: à primeira vista, graças ao scaffolding, você consegue “enganar” quem está te examinando.

E acredite, tenho recebido alguns e-mails pelo Grails Brasil de “profissionais” que começaram a VENDER sistemas feitos exatamente assim. Sinceramente, acredito que precisamos iniciar um trabalho de conscientização dos clientes a respeito deste assunto, porque estas criaturas estão simplesmente DESTRUINDO a nossa imagem profissional.

Do outro lado, acredito que deva ser também desenvolvido um trabalho junto a estes “profissionais” esclarecendo o que vêm a ser e para que deve ser usada a geração de código por estas e outras ferramentas.

Resumindo: é um problema de educação.

Não sou contra o scaffolding, mas tenho TUDO contra aqueles que se esquecem que ele é apenas um andaime, e nada mais do que isto. Este é o real problema para mim.

[sergiotaborda]

Sinceramente, acredito que precisamos iniciar um trabalho de conscientização dos clientes a respeito deste assunto, porque estas criaturas estão simplesmente DESTRUINDO a nossa imagem profissional.

Agora disseste tudo. É exatamente isso que tem que ser feito.
O pessoal só vai aprender boas práticas e formas sãs de fazer software quando isso for exigencia do mercado.
E a unica forma disso acontecer é educando os clientes.

Agora, o ponto é: em quê educar os clientes ?

coisas como métricas já foi visto que não funciona. Precisamos de algo melhor. Mais na cara.

[Thiago_Senna]

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)

Humm, concordo, em partes. Deixe-me dar minha opinião sobre scaffold, que em especial no Grails, é uma das features mais interessantes. Acredito que para a maioria dos programadores eles utilizarão o scaffold como um gerador de código passivo, ou seja, aquele código que você gera apenas uma vez e que não faz parte do processo de build do projeto. Um bom exemplo desses geradores é o próprio scaffold, wizards entre outros.

No entanto, não podemos dizer o mesmo quando o assunto é geradores de código ‘ativos’, ou seja, aqueles em que a geração de código está integrado ao processo de build do projeto e melhor ainda, o código gerado está sob controle do desenvolvedor. Assim, o desenvolvedor poderia livremente customizar o código gerado.

Inicialmente o scaffold não passa de um gerador de código ‘passivo’. No entanto, dependendo do desenvolvedor ele pode transformar o scaffold em um gerador ‘ativo’ com a ajuda dos scripts que você pode criar no Grails, por exemplo. Quando for este o caso, eu chutaria que o código gerado pode representar em média 80% do trabalho. Isso pelo menos é o que a comunidade da metologia ‘MDSD’ tem falado sobre o assunto. Assim como há ferramentas que te possibilitam criar DSL’s e seus respectivos geradores de código (xtext, mps), o mesmo pode ser feito com grails com a diferença que a DSL já existe, no caso, o GORM.

Espero ter colaborado

[kicolobo]

[quote=kicolobo]Sinceramente, acredito que precisamos iniciar um trabalho de conscientização dos clientes a respeito deste assunto, porque estas criaturas estão simplesmente DESTRUINDO a nossa imagem profissional.

Agora disseste tudo. É exatamente isso que tem que ser feito.
O pessoal só vai aprender boas práticas e formas sãs de fazer software quando isso for exigencia do mercado.
E a unica forma disso acontecer é educando os clientes.

Agora, o ponto é: em quê educar os clientes ?

coisas como métricas já foi visto que não funciona. Precisamos de algo melhor. Mais na cara.[/quote]

Acho que o primeiro ponto neste processo de educação poderia ser força-los a pensar nas seguintes questões:

• “Por que de fato estou contratando os serviços de desenvolvimento?”
  Em pelo menos 40% dos casos que pego, o desenvolvimento é completamente desnecessário (e é ai que os picaretas entram, dizendo o contrário)

• “O que REALMENTE espero obter como resultado deste serviço?”
  A partir do momento em que o cliente SABE o que quer, ao ver o resultado, ele SABE se está obtendo exatamente aquilo que desejou no início.

• “O que é um software de qualidade para mim (o cliente)?”
  Este é o ponto.

• “Por que estou contratando fulano e não ciclano? Como saber QUEM contratar?”
  Ensinar o cliente a saber COMO e QUEM contratar. Isto já aniquila metade dos picaretas de cara.

• “Como será a minha relação com este desenvolvedor após a entrega?”
  Este é o ponto. No caso dos “viciados em scaffolding” por exemplo, é justamente neste aspecto que a coisa pega. Na hora em que o cliente começar a exigir novas funcionalidades, o “coitado” do “desenvolvedor” irá implorar por um milagre.
  Se o cliente já tiver uma noção sobre como deseja ser este relacionamento após a entrega, antes de assinar qualquer contrato já evitou cair em armadilha.

[kicolobo]

[quote=http://www.itexto.net/devkico/?p=496]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)

Humm, concordo, em partes. Deixe-me dar minha opinião sobre scaffold, que em especial no Grails, é uma das features mais interessantes. Acredito que para a maioria dos programadores eles utilizarão o scaffold como um gerador de código passivo, ou seja, aquele código que você gera apenas uma vez e que não faz parte do processo de build do projeto. Um bom exemplo desses geradores é o próprio scaffold, wizards entre outros.

No entanto, não podemos dizer o mesmo quando o assunto é geradores de código ‘ativos’, ou seja, aqueles em que a geração de código está integrado ao processo de build do projeto e melhor ainda, o código gerado está sob controle do desenvolvedor. Assim, o desenvolvedor poderia livremente customizar o código gerado.

Inicialmente o scaffold não passa de um gerador de código ‘passivo’. No entanto, dependendo do desenvolvedor ele pode transformar o scaffold em um gerador ‘ativo’ com a ajuda dos scripts que você pode criar no Grails, por exemplo. Quando for este o caso, eu chutaria que o código gerado pode representar em média 80% do trabalho. Isso pelo menos é o que a comunidade da metologia ‘MDSD’ tem falado sobre o assunto. Assim como há ferramentas que te possibilitam criar DSL’s e seus respectivos geradores de código (xtext, mps), o mesmo pode ser feito com grails com a diferença que a DSL já existe, no caso, o GORM.

Espero ter colaborado ;)[/quote]

Sabe Thiago, eu acho scaffolding um recurso BEM interessante pra dar um kickstart no desenvolvimento. No entanto, o que eu observo tanto em RoR quanto em Grails é que o pessoal muitas vezes fica só nele, e simplesmente ignora o fato de que eles na realidade existem para gerar um código inicial que posteriormente será customizado, e não o código FINAL da aplicação.

Não quero dizer com isto que o trabalho de desenvolvimento bom é aquele que sempre é uma luta infinda, muito pelo contrário. O que quero dizer é que não é, de modo algum, o mamão com açucar que muitos se iludem ao se deparar pela primeira vez com o recurso.

(com certeza colaborou! )

[Thiago_Senna]

Sabe Thiago, eu acho scaffolding um recurso BEM interessante pra dar um kickstart no desenvolvimento. No entanto, o que eu observo tanto em RoR quanto em Grails é que o pessoal muitas vezes fica só nele, e simplesmente ignora o fato de que eles na realidade existem para gerar um código inicial que posteriormente será customizado, e não o código FINAL da aplicação.

entendo, usar só de scaffold para entregar uma aplicação é triste mesmo.

[kicolobo]

[quote=kicolobo]Sabe Thiago, eu acho scaffolding um recurso BEM interessante pra dar um kickstart no desenvolvimento. No entanto, o que eu observo tanto em RoR quanto em Grails é que o pessoal muitas vezes fica só nele, e simplesmente ignora o fato de que eles na realidade existem para gerar um código inicial que posteriormente será customizado, e não o código FINAL da aplicação.

entendo, usar só de scaffold para entregar uma aplicação é triste mesmo.[/quote]

não é triste, é TRÁGICO!

Imagina o efeito cascata disto.

[sergiotaborda]

[quote=sergiotaborda][quote=kicolobo]Sinceramente, acredito que precisamos iniciar um trabalho de conscientização dos clientes a respeito deste assunto, porque estas criaturas estão simplesmente DESTRUINDO a nossa imagem profissional.

Agora disseste tudo. É exatamente isso que tem que ser feito.
O pessoal só vai aprender boas práticas e formas sãs de fazer software quando isso for exigencia do mercado.
E a unica forma disso acontecer é educando os clientes.

Agora, o ponto é: em quê educar os clientes ?

coisas como métricas já foi visto que não funciona. Precisamos de algo melhor. Mais na cara.[/quote]

Acho que o primeiro ponto neste processo de educação poderia ser força-los a pensar nas seguintes questões:

• “Por que de fato estou contratando os serviços de desenvolvimento?”
  Em pelo menos 40% dos casos que pego, o desenvolvimento é completamente desnecessário (e é ai que os picaretas entram, dizendo o contrário)

• “O que REALMENTE espero obter como resultado deste serviço?”
  A partir do momento em que o cliente SABE o que quer, ao ver o resultado, ele SABE se está obtendo exatamente aquilo que desejou no início.

• “O que é um software de qualidade para mim (o cliente)?”
  Este é o ponto.

• “Por que estou contratando fulano e não ciclano? Como saber QUEM contratar?”
  Ensinar o cliente a saber COMO e QUEM contratar. Isto já aniquila metade dos picaretas de cara.

• “Como será a minha relação com este desenvolvedor após a entrega?”
  Este é o ponto. No caso dos “viciados em scaffolding” por exemplo, é justamente neste aspecto que a coisa pega. Na hora em que o cliente começar a exigir novas funcionalidades, o “coitado” do “desenvolvedor” irá implorar por um milagre.
  Se o cliente já tiver uma noção sobre como deseja ser este relacionamento após a entrega, antes de assinar qualquer contrato já evitou cair em armadilha.
  [/quote]

Tudo isso parece bom, mas é muito etério. Precisa ser algo mais concreto.
Por exemplo, ensinar como e quem contratar. Que parametros ele usaria. O que ele tem que saber ?

[Felagund]

Eu tbm fiquei encando quando descrobri o magico script/generate scaffold do Rails.

Porém quando começei a analisar o código senti enjoado, aquele código não me dizia nada, pra mim aquilo era lixo.
Então fui estudar pra ver por que saiam aqueles códigos, logico funcionava,mas se eu adicionasse um campo depois na tabela, eu nem fazia ideia de como adicionar, e se eu queria um regra antes de salvar?

Descobri que me sentia melhor escrevendo as actions do que usando scaffold, hj só uso esse recurso caso seja um tela de cadastro básico, exemplo: UF, Cidade, etc.

O que sinto falta nessas metodologias é uma explicação do por que as coisas são assim, muitos veem um video e se encantam (eu fui um desses), e saem achando que tudo é facil, e esbarram justamente na customização disso. Muita gente deveria ao menos se informar de como funciona o framework (seja Rails ou Grails), antes de sair por ai usando generators.

E seu amigo que ta fazendo o TCC ta com sérios problemas hein.

[]'s

[Bruno_Laturner]

[quote=kicolobo]Acho que o primeiro ponto neste processo de educação poderia ser força-los a pensar nas seguintes questões:

• “Por que de fato estou contratando os serviços de desenvolvimento?”
  Em pelo menos 40% dos casos que pego, o desenvolvimento é completamente desnecessário (e é ai que os picaretas entram, dizendo o contrário)

• “O que REALMENTE espero obter como resultado deste serviço?”
  A partir do momento em que o cliente SABE o que quer, ao ver o resultado, ele SABE se está obtendo exatamente aquilo que desejou no início.

• “O que é um software de qualidade para mim (o cliente)?”
  Este é o ponto.

• “Por que estou contratando fulano e não ciclano? Como saber QUEM contratar?”
  Ensinar o cliente a saber COMO e QUEM contratar. Isto já aniquila metade dos picaretas de cara.

• “Como será a minha relação com este desenvolvedor após a entrega?”
  Este é o ponto. No caso dos “viciados em scaffolding” por exemplo, é justamente neste aspecto que a coisa pega. Na hora em que o cliente começar a exigir novas funcionalidades, o “coitado” do “desenvolvedor” irá implorar por um milagre.
  Se o cliente já tiver uma noção sobre como deseja ser este relacionamento após a entrega, antes de assinar qualquer contrato já evitou cair em armadilha.
  [/quote]

Problema é cliente não querer ser educado ou reclamar que ele já sabe o que quer, e ele dizer que e se precisasse de ajuda para saber o que ele quer, ele procuraria um psicólogo, não você. :roll:

Não é um problema só na TI. É mesma coisa que você for uma concessionária de carros e o vendedor atendente te perguntar se você viaja muito, é casado, solteiro, tem família grande. Isso é pra saber se você precisa de um hatch ou um sedan, não pra saber da tua vida.

[kicolobo]

[quote=Felagund]

E seu amigo que ta fazendo o TCC ta com sérios problemas hein.

[]'s[/quote]

Opa, ele não é meu amigo