A verdade absoluta sobre os projetos de hoje em dia...

http://www.uoregon.edu/~ftepfer/SchlFacilities/TireSwingTable.html

LOL, muito dez!!

Nossa, muito bom esse....

Estou feliz em saber que isso não a contece só comigo, apesar de que por aqui no meu trabalho eu faço quase todas as funções....

Gustavo Guilherme BacK

Nossa cara ... Bem legal !!

É o que se pode chamar de "analogia perfeita"...

Nossa, fazia tempo que não via esse desenho eheheh.

Para vocês verem, ele deve ter pelo menos uns 10 anos e ainda nos dias de hoje, infelizmente, é atual.

TaQ wrote:Nossa, fazia tempo que não via esse desenho eheheh.
Para vocês verem, ele deve ter pelo menos uns 10 anos e ainda nos dias de hoje, infelizmente, é atual.

Sim, e isso nunca vai mudar - é o estado da arte na engenharia de processos compartamentalizada onde cada um é responsável por dar sua visão sobre o projeto... Extreme Programming tah aih pra dar uma força nisso, mas mesmo assim não resolve o problema mais simples de subestimar de todo esse universo:

O CLIENTE NÃO SABE O QUE QUER, E QUANDO SABE, NÃO SABE EXPLICAR

Um fato que eu presenciei ta sendo, no minimo, preocupante:

O cliente chegou e disse: "Olha, nos somos a empresa X, e queremos mudar o nosso site. Eh algo bem simples, com a chamada para a ultima noticia cadastrada aparecendo na home, e depois links para as outras noticias.. tudo texto puro, nada complicado. Ah, e queremos tambem um formulario de contato, alem de partes institucionais, que nao precisam de banco de dados.."

A empresa vai la e faz o site, sem pattern algum, usando tudo direto no JSP ( sim, tratamento de erro, conexao com o bando de dados... bem no estilo PHP )..
Dia da entrega, chegam com o sistema funcionando e vao instalar. Depois de instalado, o cliente pede para ver o codigo e diz: "ah, mas assim como foi desenvolvido nos nao queremos.. tem que usar Java Beans".

A empresa volta e refazer todo o sistema usando Java Beans ( ou seja, agora nao ficou tudo direto nos .jsp, houve um principio de separacao, por mais simples que tenha sido ).

Nova instalacao, cliente ve o codigo fonte de novo e diz: "Opa, mas nao eh esse tipo de Java Bens.. nos queremos que seja EJB"... ( apenas para lembrar, o site contem mais paginas HTML puras do que paginas que precisem de acesso a algum tipo de dado dinamico ).

A empresa volta e refaz tudo, usando um monte de EJB.. Novo dia de instalacao, o sistema roda absurdamente lento, cliente nervoso etc...
Depois de muita briga, o cliente novamente muda de ideia e diz: "ok, agora nos queremos que seja mudado o sistema.. agora nos queremos que seja feito usando MVC, e eh obrigado a ter os patterns X, Y, K e Z".

Isso eh fato, e com certeza acontece em muitos outros lugares, em produtoras "profissionais" tambem.
O cliente dizer o que espera do sistema, de quais funcionaliaddes deseja eh uma coisa.... mas o cliente dizer *como* tem que ser feito, e o que usar, ja eh o cumulo ( tao absurdo quando a empresa de desenvolvimento aceitar sem questionar )..

Rafael

Rafael,

Esse exemplo que você deu é real ?

Eu nunca vi cliente dizer que quer utilizar tecnologia A, B ou C, muito menos a D

O que já aconteceu é: utilizamos a tecnologia XXX, você conhece ? Pode desenvolver sobre essa plataforma ?

Eu até concordo que um cliente com o mínimo de conhecimento técnico nunca aceitaria um projeto baseado em JSP's acessando banco, mas a descer a dizer que quer EJB's, Pattern xyz, MVC, é absurdo. O que pode acontecer é que você arranca até as calças dele no orçamento.

t+

Eh real sim, e recente

Rafael

net_sandro wrote:Esse exemplo que você deu é real?

Se o dele não for, não se surpreenda, pq eu tenho uns 4 ou 5 desses pra confirmar

net_sandro wrote:Eu até concordo que um cliente com o mínimo de conhecimento técnico nunca aceitaria um projeto baseado em JSP's acessando banco, mas a descer a dizer que quer EJB's, Pattern xyz, MVC, é absurdo. O que pode acontecer é que você arranca até as calças dele no orçamento.

Acontece sim - acho que podemos chamar de "Sindrome Do Gerente Que Le InfoExame/JavaMagazine/etc E Nunca Fez Nada Concreto No Mundo Real". Eh tipico.

Alias, se temos Patterns, XML (alias, a salvacao da lavoura), XSLT, EJB, JDO, MVC, JSTL, IEEE, AIDS, UFO e tantas outras siglas interessantes, por que utilizar algo pratico e adequado para o caso?

Eh o extremo oposto do cara que faz um sistema complexo totalmente baseado na camada de visao (JSP/PHP/ASP para tudo, misturando isso no HTML).

Marcio Kuchma

Notícias, artigos e o maior fórum brasileiro sobre Java