Vejam esse interessante artigo (um desabafo, na verdade) que a Cindy Dalfovo postou no Disk Chocolate:
http://diskchocolate.com/blog/2010/04/23/20-anos-depois-ainda-nao-entendemos-reusabilidade/
Vocês concordam?
Olá!
Quanto a “usabilidade” posso afirmar que para muitos usabilidade significa ctrl+c , ctrl+v ao invés de gerar um framework/lib em que o código pode ser reaproveitado, é claro que esse cenário é muito melhor do que a 20 anos atrás, mesmo tendo empresas que querem produzir software que nem pãozinho em padaria, mas os desenvolvedores no geral estão melhor “munidos” de conhecimento.
Quanto a complexidade dos frameworks eu discordo em partes, claro que mesmo depois do annotations ainda temos que fazer N configurações mas eu agradeço por fazê-las, pois se o Hibernate por exemplo fosse simplista, provavelmente não se encaixaria em boa parte das situações que o aplico. Se o framework X tem N configurações é justamente para abranger o maior número de casos e promover ainda mais a reusabilidade, apesar de tudo, entendo o ponto de vista dela pois sei o parto que era escrever um EJB 2.x.
Eu as vezes me sinto como ela. Alguns sistemas estão burocráticos demais.
Mas sinto as vezes que a questão de persistencia em OO ainda não é um assunto bem resolvido. O hibernate é um ótimo mapeamento, mas ainda não é de longe tão trivial de usar quanto era manipular dados na época da programação estruturada.
Por outro lado, hoje também modelamos problemas mais complexos que, por consequência, exigem mais estrutura para serem modelados.
óitmo post
Porém eu discordo disso:
O weka, processing, hibernate(framework que não deixa de ser um conjunto de bibliotecas) e Spring não são bandaids. São ótimas ferramentas e eu poderia citar mais uma duzia de boas soluções.
Existe bibliotecas ruins?
Deve existir até pq qualquer um pode fazer uma biblioteca ou framework.
já add o blog aos meus favoritos…
[]`s
Eu acho meio complicado, sabe? Pensando por um lado, os programadores iriam escrever seus próprios ArrayList, Hashes e Threads. Isso eu acho que, além de custoso, seria um tanto perigoso, porque quem melhor pra escrever as APIs do que os caras que entendem grande parte da arquitetura da JVM? Não digo aquele overview de arquitetura, mas aquela coisa detalhada mesmo.
Por outro lado, acho que sair procurando jars pela Internet, em vez de programar algo trivial (ou construir uma classe que seja meio que essas “Tools” que a gente ve por aí) pra resolver um problema não seja programação. É pegar umonte de Lego usado e pronto. Fica aquela coisa colorida, ridícula e que, se precisar dar uma manutenção detalhada, vai custar muito caro pro programador.
acho que a mulher e principiante… e que ela usa os frameworks como bandaids por que ela quer…
cada framework desses por exemplo… Spring,Hibernate,Struts etc… voce tem 2 opções.
1 - Você aprende eles porca-mente em 5 minutos… porca-mente que eu falo e do jeito que a maioria sabe o “Fazer rodar” o mínimo para poder trabalhar.
2 - Pegar um livro de 500 paginas e aprender direito a ferramenta isso deve demorar 1 mes se a pessoa for dedicada.
o que o ocorre e que 90% das pessoas tem preguiça e esse frameworks sao muito tramquilos de aprender se estudados direito o Struts e simplesmente uma implentação do padrão de projeto front controler etc… e se voce for reinventar a roda toda vez.
Eu conheço a autora do blog e o que ela tem, definitivamente, não é preguiça. Eu mesmo, com anos de estrada, já me bati com arquivinhos de configuração em diversos frameworks, como o próprio Hibernate ou o Spring. O Hibernate era ainda muito pior antes do Java 5, quando você tinha que recorrer a dezenas de xmls separados da sua implementação de classe concreta.
Um problema que já vi em muita empresa é o pessoal procurar frameworks e confiar em qualquer coisa. Resultado, o projeto desse framework depois de um tempo é abandonado e a empresa fica na mão. Eu mesmo tenho um pé atrás ao escolher frameworks e procuro as que existam há alguns anos no mercado, que tenham uma equipe já grande e consolidada por trás.
Acho que o pessoal não compreendeu o que ela disse, ou eu não compreendi 
Ao que me parece, a questão é a burocracia das bibliotecas, agora vai me dize quem uma classe em JPA é bonita com todas aquelas @Annotations, ou vai me dizer que um XML tbm é bonito com todas aquelas TAGs.
Concordo plenamente, a pior parte de um sistema é desenvolver a parte chata, mas que é a base para quem usa, lógico que é muito mais atraente trabalhar focado em logica, do que desenvolvendo cadastros básicos, mas enfim, nem tudo são flores, e não importa a sua profissão.
Concordo que muita coisa deveria ser muito simples, e pratica, e principalmente focada em extensibilidade, eu sou fã do conceito de classes abertas do Ruby, acho que você poderia alterar uma classe a qualquer momento, EU quero que essa classe seja do meu jeito e que se dane o que os projetistas do java pensaram quando criaram a classe String.
Quando a essas malditas configurações, aaaaaaaaaaaaa não vejo a hora da Convenção ao inves de Configuração chegar ao java, sabe, existem padrões em todos os projetos, e por que eu tenho que configurar tudo isso a cada minuto? Por que não posso customizar esse framework para ser do meu jeito? Por que tanto XML? Por que tanta Annotation? Por que tantos Frameworks? Essa ultima é facil, por que o cara não conseguiu usar um framework que ja tinha, criou o seu e disponibilizou, e vamos a nova bola de neve ehhehehe.
Concordo em muitos pontos, porém, ainda acho que as bibliotecas são muito uteis em alguns casos, e a escolha deve ser bem feita
Em momento nenhum ela falou que uma biblioteca não é útil. Mas eu concordo com a visão dela de que alguns problemas recorrentes demais, como persistência, ainda exigem muitas voltas e burocracias.
Veja bem, nós precisamos persistir dados praticamente desde que a informática foi inventada. E ainda não temos uma solução muito limpa e elegante.
[quote=ViniGodoy]Em momento nenhum ela falou que uma biblioteca não é útil. Mas eu concordo com a visão dela de que alguns problemas recorrentes demais, como persistência, ainda exigem muitas voltas e burocracias.
Veja bem, nós precisamos persistir dados praticamente desde que a informática foi inventada. E ainda não temos uma solução muito limpa e elegante. [/quote]
Se houvesse uma padronização de como um sistema deve ser desenvolvido seria fácil desenvolver uma solução elegante, com poucas configurações e etc. Mas justamente pela maneira de desenvolver ser muito “livre”, o framework acaba tendo de ser muuito flexível para atender a boa parte dos casos( Entenda-se por N configurações ), se for seguir por essa linha de pensamento quem está errado somos nós.
Olá,
Ela fala em algo bem importante, a geração de código automático pelas IDEs e afins. E eu sempre pensei dessa forma, se uma ferramenta for ela a responsável por gerar zilhões de linhas de código para você que ela seja á ÚNICA responsável por esse código.
Foi por isso que em um projeto eu bati o pé com o meu atual chefe - que ná época (mais de 2 anos atrás) -, ele insistiu para usarmos a implementação de JSF chamada de Woodstock, eu fiz os meus argumentos alegando eu que a ferramenta não tinha uma comunidade muito sólida, existiam ferramentias com mais tempo no mercado e como conseqüência, mais códigos feitos, mais gente trabalhando e mais problemas resolvidos. O argumento dele era que a ferramenta era “prática” fazendo uso de recurso visual (tipo matisse) para produzir as telas. Então eu falei: “quem vai dar manutenção nesse código tosco que o Woodstock gera?”
Ela fala do ponto de complexidade das ferramentas e frameworks, também estou de acordo. Eu ficava pensando na época no Struts e então eu me perguntava, onde diabos está a facilidade nisso aqui, e na verdade ninguém sabia me explicar de fato as vantagens de usá-lo ao invés do formato: JSP + Servlets, e isso foi meio que empurrado guela abaixo.
Abomino com todas as forças as fábricas de softwares. Porém de quem é a culpa? Da fábrica que lhe trata como code monkey ou do programador que relaxe e deixa se levar por tal situação?
Com relação a burocracia das ferramentas, eu penso o seguinte, o Hibernate por exemplo ele elimina da mão do programador muita coisa.
Existe burocracia pq existe muita complexidade a ser tratada.
Porém só temos o O/RM pq alguém não estava contente com a solução que existia na época.
Bom se ela reclama de que existem problemas antigos ainda não resolvidos, critica os principais frameworks/tecnologias do mercado E afirma que adora a parte de “encontrar e implementar soluções” na programação… bom pelo menos para mim está muito claro o que ELA deveria fazer…
sinceramente eu sou totalmente contra o uso desenfreado de frameworks. Se não há realmente um excelente motivo para usá-lo, então não use.
O real problema não está no framework, está em quem os utiliza!
[quote=ViniGodoy]Em momento nenhum ela falou que uma biblioteca não é útil. Mas eu concordo com a visão dela de que alguns problemas recorrentes demais, como persistência, ainda exigem muitas voltas e burocracias.
Veja bem, nós precisamos persistir dados praticamente desde que a informática foi inventada. E ainda não temos uma solução muito limpa e elegante. [/quote]
Sou da opinião que ainda não temos problemas limpos e elegantes para solucionar. 
[quote=MaiqueL]Com relação a burocracia das ferramentas, eu penso o seguinte, o Hibernate por exemplo ele elimina da mão do programador muita coisa.
Existe burocracia pq existe muita complexidade a ser tratada.
Porém só temos o O/RM pq alguém não estava contente com a solução que existia na época. [/quote]
O hibernate não elimina a complexidade, ele elimina a “repetição de rotinas”, e só isso, a complexidade continua existindo, mesmo sendo de outra forma. O seu ponto tá certo!
[quote=Grinvon][quote=MaiqueL]Com relação a burocracia das ferramentas, eu penso o seguinte, o Hibernate por exemplo ele elimina da mão do programador muita coisa.
Existe burocracia pq existe muita complexidade a ser tratada.
Porém só temos o O/RM pq alguém não estava contente com a solução que existia na época. [/quote]
O hibernate não elimina a complexidade, ele elimina a “repetição de rotinas”, e só isso, a complexidade continua existindo, mesmo sendo de outra forma. O seu ponto tá certo![/quote]
sem comentários…
Em certos momentos me sinto também como a autora do blog. Antigamente no Hibernate quando se fazia as configurações utilizando XML, era terrível. Eu procuro utilizar bibliotecas e frameworks que já estão há alguns anos no mercado e que não corre o risco de ser abandado, como por exemplo, o hibernate. E também não devemos confiar em qualquer coisa, como o Vinny disse. Uma coisa que ainda acho complicada são as várias configurações que devemos fazer em arquivos WEB.XML das aplicações web quando queremos utilizar algum framework. Não seria mais fácil apenas adicionar o jar no classpath? E funcionar sem aquele monte de configurações? Enfim, ainda temos bastante coisa para mudar.
eu detesto xml, mas é complicado você simplesmente adicionar um jar e a mágica acontecer.
Eu fico pensando. Por que alguns desenvolvedores de frameworks gostam de criar vários arquivos em xml para configurar a aplicação? Será que por achar bonito aquele monte de XML com aquelas tags? Em certos momentos uma configuração do XML é necessária, como por exemplo, o Persistence.XML do JPA, por ter a configurações de conexão e entre outras coisas. Tempos atrás quando tentei utilizar o Spring, nossa foi sofrivel com aquele monte de XML. Não sei como o Spring está hoje, mas espero que melhor sem aqueles XML. Muitos de nos devemos procurar entender melhor o conceito de reusabilidade, por as vezes me sinto me agofando em um monte de burocracia.
Em questão de reusabilidade também para driblar esses montes de frameworks que surgem por ai, sem saber o rumo deles. Eu procuro desenvolver soluções proprias, mesmo que gaste algum tempo, com isso evito de ter que cair nas armadilhas de alguns frameworks, que não sabe se ficam ou se vai.