Proposta de discussão: Sobre Frameworks
Isso não pretende ser um post. Na verdade será uma pergunta aberta à comunidade leitora deste blog.
Frameworks já deram muito o que falar por aqui. Basta dar uma olhada no artigo Sobre Frameworks… escrito pelo Raphael há algum tempo atrás. Eu, ao contrário de muitos de meus colegas, não tenho opinião fechada sobre este tema. Existem frameworks que eu odeio (Hibernate), outros que eu não vejo maiores problemas no uso apesar das críticas (Struts) e alguns poucos que eu gosto muito (no momento, Django).
Fato é que frameworks, por princípio, oferecem um quadro de trabalho dentro da qual temos que nos acomodar. Estava assistindo agora a uma palestra interna da empresa sobre este tema, e o palestrante levantou uma vantagem e uma desvantagem no uso de frameworks que me chamaram a atenção.
A vantagem apresentada foi que frameworks ajudam a desenvolver 80% do trabalho repetitivo de uma aplicação (CRUD por exemplo). Basicamente, eliminando a repetição. A desvantagem é que ele engessa um pouco a criatividade e pode tornar difícil os 20% não previstos nos casos comuns. Alguém na sala acrescentou que o problema é que em muitos casos, para resolver os casos não previstos temos que contornar o framework.
Eu concordo com estes dois pontos. As porcentagens não são nenhum pouco científicas, mas pela minha pouca experiência eu diria que elas são bem aceitáveis. E pareceu ser consenso na sala de que estes 80% justificam a existência do framework. De certa forma eu também concordo com isso.
A minha pergunta, provocativa, é a seguinte: supondo que os 80% que o framework resolve são os problemas genéricos que todos os projetos têm, não seriam os 20% restantes (que frameworks tornam difícil) o que realmente agrega valor e diferencia o produto? Ou seja: no final das contas, os frameworks não atrapalhariam o desenvolvimento daquilo que é a razão de um sistema existir?
Bingo!
Agora to meio sem tempo, mas vou voltar nesse post. Soh pra deixar um ponto, se voce conhece o desenvolvedor do framework ou pelo menos tem acesso a fonte, voce muitas vezes pode modificar soh um pouquinho as assumptions do framework e aqueles 20% se tornam 5%.
Um exemplo eh uma experiencia que eu tive em que o framework passava um XMLStreamWriter em uma callback que voce podia implementar. Meu codigo usava OutputStream e escrevia o XML na mao. Seria um tormento criar adapters pra fazer o “workaround”. Olhando o codigo eu vi que eles criavam a XMLStreamWriter de um OutputStream, entao tudo que bastava era eles me passarem o que eu precisava (uma pequena modificada no codigo do framework me salvou o dia).
Acho que o único problema da utilização de frameworks são as pessoas da equipe. Normalmente alguns desenvolvedores não querem aprender tecnologias novas, por isso ficam inventando desculpas para não usar frameworks. Desculpas como “limita a criatividade”, “engessa o sistema”, “utilize o método Socrático”, etc.
Frameworks são criados para facilitar, em todos os sentidos. Facilitar a implementação de funcionalidades comuns e que desprendem tempo de desenvolvimento, facilitar a manutenção, padronizar, dentre outras vantagens como confiabilidade, segurança e velocidade.
Para o cliente, pouco importa se o sistema usa Hibernate ou JDBC direto. O que importa para o cliente é o negócio, a funcionalidade. Para a equipe de desenvolvimento os frameworks são muito importantes, principalmente pela redução de tempo de desenvolvimento (estratégia comercial).
E não me venha com essa teoria 80-20, isso é desculpa de quem não quer aceitar os benefícios dos frameworks.
Homer: posso concluir que de cara você considera que qualquer framework sempre será positivo, não importa qual. Nesse ponto somos bem diferentes: eu acho que alguns valem muito a pena e realmente ajudam, outros poderiam ser jogados no lixo.
Concordo com você de que para o cliente não importa usar JDBC ou Hibernate. Para mim importa eu ser eficiente e rápido. E no caso achei o teu exemplo infeliz pq sinceramente eu acho que sou mais eficiente e feliz com JDBC.
E quanto a falar que 80-20 é desculpa para nao aceitar os benefícios, e queé coisa de quem tem medo de experimentar tecnologias novas, duas respostas:
1) Frameworks não são sinônimos de tecnologias novas. As vezes eles trazem inovações, mas muitas vezes são apenas uma forma de empacotar várias libs e patterns.
2) Não sei se este comentário se referia diretamente a mim ou não, mas já tomando as dores: eu conheço pouca gente que goste tanto de mexer em novas tecnologias, frameworks, padroes, protocolos e afins quanto eu. Taí o Raphael que não me deixará mentir.
Bart (Homer e Bart..a coisa tá em família aqui
)
Mexer no fonte do framework muitas vezes é uma solução viável e interessante. Eu mesmo já mexi em fontes do Tomcat, do Struts e de algumas libs em C e Java para obter alguns resultados que eu precisava. Este aliás é uma das maravilhas do software livre: não funciona como quer? abra e mexa. Lindo.
Mas aí, você há de concordar que você está “customizando” o framework para o teu uso. Já não é algo mais tão genérico…..se bem que o exemplo que você deu não tira o lado genérico da coisa.
Anyway, acho que a proporção do 80-20 é uma média, mas existem ferramentas que tem um design tão bem feito que o 20% cai pra 5% naturalmente. Citando o exemplo que eu dei acima, o Django é um deles.
[]s
Miguel, concordo que nem todos os frameworks são bons. Mas temos que reconhecer que existem uns poucos e bons no mercado. Estou falando de Hibernate, Spring, Struts, Log4j, JUnit, Lucene, Tiles, etc…
Também concordo que frameworks não são novas tecnologias, mas imagine uma equipe que não usa frameworks: qualquer framework será uma “nova técnica”.
Sou a favor da utilização de frameworks pela facilidade e segurança oferecidas. Digo isso por experiência própria: as vezes criar “pequenas funcionalidades” fica mais caro do que já usar essa funcionalidade “pronta” com algum nome comercial que já foi testada e utilizada em outros projetos.
Homer,
uma coisa importante é definir a diferença entre lib e framework. Para efeito desta discussão, estou assumindo que framework oferece uma lib e uma arquitetura na qual você tem que se encaixar.
Tomcat por exemplo oferece uma implementação de servlets, e define como e onde vc tem que organizar seu código, e faz isso bem de forma pouco intrusiva. Em relação aos exemplos que você deu acima, os que eu considero como frameworks são o Hibernate, Spring, Struts, e JUnit. Desses, JUnit eu gosto bastante (é simples e focado), Struts tem seus problemas mas nao me desagrada, Spring eu conheço muito pouco mas acho que usado de forma parcimoniosa tem seu valor e HIbernate eu abomino.
Log4J, Lucene e Tiles me parecem ser libs que oferecem serviços e que podem ser usadas dentro do seu sistema. Log4J eu uso muito e acho extremamente util. Lucene eu não conheço mas só ouvi elogios. Tiles eu acho muito trabalho pra pouco resultado prático.
Portanto vamos deixar algo claro: apesar de eu achar interessante certas soluções caseiras (mas isso é coisa pra outro post), eu não tenho nada contra reuso de código, uso muitas libs externas em projetos meus e acho otimo.
Log4Dev » Proposta de discussão: Sobre Frameworks…
Frameworks ajudam a agilizar o desenvolvimento dos 80% das features repetitivas de qualquer sistema, ou engessam e dificultam a implementaçao dos 20% que realmente agregam valor ao produto?…
Olha só, se a preocupação do Homer é com o desenvolvimento em equipe (o que é válido), ele poderia lembrar-se que a stack da Microsoft é ainda a mais usada por aí. ASP (VBScript) ainda é uma das linguagens mais utilizadas para desenvolvimento em web.
O engraçado: eu já trabalhei em uma empresa que tinha a equipe de web tinha ~10 desenvolvedores, todos com experiência em ASP, SQLServer… enfim, uma shop Microsoft. Já tinham anos rodando com aquilo. Já tinham experiência, já tinham projetos, já tinham código que poderia ser reutilizado. Mesmo assim, o CTO da empresa ficava batendo na tecla que queria migrar tudo para .NET.
Pq? “Pq .NET é um framework mais moderno.”, dizia ele, ” e pq é a evolução natural.”
No fim das contas, foram alguns meses arrumando gente pra treinar o pessoal, tempo gasto para aprender coisa que eles já sabiam fazer, código que teve que ser reescrito… e duvido que eles tenham tido alguma melhora em prazos de entrega para o cliente, menos bugs, menos custos de operação de hardware. Nada, nada, nada… foi uma mudança apenas pelo “bem-estar” do CTO, que não queria ficar com a sensação de estar usando tecnologia “atrasada”.
Enfim, a máxima de que termos que usar os frameworks pq eles sempre oferecem benefícios não é tããão válida assim.
Na outra ponta, poderíamos pensar o seguinte: que tal se, ao invés de ter uma equipe de 12 pessoas em um projeto, o que levaria ter 12 pessoas que tenham familiaridade com um conjunto de ferramentas (e aí, obviamente, nos levando a escolher um framework), que tal diminuir a equipe para 3 ou 4 que sejam (a) mais experientes/produtivos e (b) capazes de utilizar ferramentas mais poderosas?
Com tempo enviarei uma resposta mais completa mais aqui vai algo rápido: Usar frameworks é muitas vezes não ter que reinventar a roda, simples assim, é um padrão de modelo de software focado em reuso.
Como é possível criticar uma idéia tão básica? E ainda para isto citar “instancias” destas idéias que deram errado?
O surgimento do padrão “framework” foi natural e sempre vai existir, implementações ruins temos em todas as esferas de invenções, em qualquer área, isto não afeta os conceitos, que são provados como válidos ao encontramos boas implementações dos mesmos, o que temos de sobra ao falar de frameworks para desenvolvimento de software.
IMHO esta conversa é uma grande confusão entre conceito e implementação.
ps. É quase como criticar a construção de APIs.
Outra coisa, que é separada mas está relacionada: prestem muita atenção no “razão do sistema existir”.
Em análise cuidadosa, muito das necessidades de sistemas enterprise não correspondem às necessidades reais dos consumidores, mas apenas de necessidades impostas pelas empresas que são os players do mercado.
Qual a “razão do sistema existir” em tecnologia do sistema financeiro? Nosso sistema bancário/financeiro é um dos mais modernos do mundo, temos uma infinidade de produtos oferecidos pelos bancos. Mas a pergunta: toda essa tecnologia é eficaz, no Brasil, para que a sociedade use o sistema financeiro como propulsor de economia sólida? As pessoas são mais produtivas graças a essa tecnologia? Parece-me que não.
Uma solução como o Kiva (que o Sorô já falou aqui) tem bem menos tecnologia, mas supre muito melhor a solução para a coisa. Framework ou não.
Bruno, do mesmo jeito que você pode considerar que é absurdo alguém invalidar o conceito de frameworks uma vez que existem boas implementações, eu posso dizer que acho absurdo valida-lo, simplesmente porque existem algumas implementações que eu acho horríveis.
Diga-se de passagem, o conceito em si eu acho lindo: usar um arcabouço que permitirá ser mais produtivo, mais eficiente, mais moderno e mais bonito. Tanto que eu usei e uso muito framework, indo atrás da premissa. O fato é que a realidade me mostrou alguns exemplos ruins, e hoje eu sou mais criterioso naquilo que eu uso.
E indo mais a frente: de fato, nos 80% de problemas comuns que frameworks resolveriam eles em geral são mais bonitos, mais eficientes, mais sólidos e por aí vai. Não coloquei em dúvida isto no texto acima. Apenas questionei a validade dos outros 20% ou 15% que requerem mais trabalho e uma boa dose de workaround.
Raphael,
nós já conversamos sobre isso (quando discutíamos sobre frameworks alias) e vou aproveitar que vc mencionou a questão da utilidade de um sw pra sociedade para ressaltar um ponto de discordância nosso.
Eu acho extremamente necessário e interessante discutir se a forma como fazemos as coisas hoje em dia é a melhor. Temos uma tendencia a achar que o que está aí é a única forma correta, e que não existe coisa melhor. A evolução humana se fez a partir de quebras de paradigmas.
Mas eu não vejo uma relação direta desta quebra de paradigmas com a forma como um sw é organizado internamente. Eu posso usar uma organização futurista para fazer sw de padaria, e posso fazer software com FUNCIONALIDADES INOVADORAS usando uma organização de sw mais padrão. E no meu entender o ponto em dicussão tem mais a ver com organização e estrutura de SW do que com inovação do produto final.
[]s
Miguel, se você me trouxer algum exemplo de software (ou sistema) que trouxe alguma revolução usando as fórmulas tradicionais, eu concordo com você.
Ao meu ver, inovação verdadeira impõe o abandono de fórmulas antigas. Se você utilizar processos já existentes, você vai ter produtos já existentes.
E um software não tem valor nenhum se ele já faz o que os outros já fazem. A única coisa em que há real valor está no design, ainda mais num mundo com custo de duplicação e de distribuição assintoticamente nulo.
Miguel, você disse “uso muitas libs externas em projetos meus e acho otimo”. Se você está considerando, por exemplo, o Log4j uma simples lib, por que não considerar o Hibernate uma “lib” também, já que ele fica, de certa forma, transparente para o resto da aplicação?
Acho que essa discussão está sem foco. O que estou considerando como “framework” pode ser considerado como “lib” por outro. Eu não considero o .NET Framework o mesmo “framework” desta discussão. Compararia .NET com JAVA e todo ambiente .NET (ISS, ASP.NET, etc) com o J2EE (container web, servlets, etc).
Usar um framework, para mim, é usar um conjunto de funcionalidades prontas para simplificar ou acelerar o desenvolvimento.
Em um ponto eu concordo com o Raphael: “que tal diminuir a equipe para 3 ou 4 que sejam (a) mais experientes/produtivos?”. Isso funciona! Minha equipe tinha 4 programadores júniores/plenos que não conheciam frameworks (Hibernate e Spring, no caso) mas conseguiam produzir da maneira básica de programação. Num outro projeto, o desenvolvimento ficou com 2 programadores sêniores e a produtividade foi muito maior. Agora vem a explicação: estes dois programadores, mais produtivos, tinham familiaridade com Hibernate e Spring e usufruiram destes frameworks para diminuir o tempo de desenvolvimento. E o projeto foi um sucesso (as necessidades do cliente foram atendidas e no prazo).
Miguel, só por curiosidade, por que você “abomina” o Hibernate?
Miguel, nem todo framework é engessado, no mínimo eles oferecem opções de “fallback” para que você possa _não_ usá-lo. É o caso do Hibernate, que quando a coisa encrenca você pode ir direto para o SQL. Tudo bem que isso fica com cara de gambiarra, mas assumindo que um framework nunca vai atender 100% de todos os projetos possíveis, faz sentido ter esse recurso.
Acho que frameworks se tornam mais problema que solução em 2 casos:
1 - O framework NÃO tem estratégia de fallback e se ele não prevê o caso que vc quer executar, vc está lascado.
2 - No seu projeto vc está usando muito mais a estratégia de fallback do que o próprio framework OU a estratégia de fallback é muito mais simples de usar do que o framework.
Infelizmente, acho que o item 2 só dá pra descobrir depois que vc entrou em um projeto com esse framework
E pode ser que para o projeto seguinte o framework seja bom 
Homer,
sinto te desapontar, mas quando o Raphael menciona a redução da equipe para 3 ou 4 mais experientes visando o uso de ferramentas mais poderosas, Spring e Hibernate passam longe.
Não gosto do Hibernate por N motivos. Acho que ele pretende resolver muita coisa ao mesmo tempo. Não gosto de HQL, não gosto da forma como ele resolve certos mapeamentos criando aberrações na base de dados que faria qualquer DBA decente querer se matar, acho que as configurações de base dele um lixo e pra fazer qualquer coisa decente, tenho que virar expert, sendo que neste tempo eu poderia fazer o mesmo com JDBC. A questão da portabilidade pé um mito (peça ao Ronnie que comentou acima pra te contar como foi migrar uma base do Oracle pro SQL Server) e sempre que o projeto precisava de uma resposta rápida para buscas extremamente pesadas, era necessário partir pro bom e velho SQL (ponto a menos pra portabilidade). E quando eu digo projetos grandes, eu falo de coisas na escala do sistema de gerenciamento dos PoupaTempos do Estado de São Paulo e em sistemas de gerenciamento de empresas de logistica.
E como eu sei que alguém vai querer dizer que a culpa não é da ferramenta e sim do mau uso dela, eu digo: eu considero que uma ferramenta que me faça sentir burro incompetente e altamente improdutivo é ruim. Django tem um sistema de ORM, e eu nunca tive problemas com ele e sou bem produtivo.
Mas obviamente, existe o Hibernate 3…..
@Homer
Vou aproveitar a pergunta pra apontar um link e colocar duas perguntas pra pensar…
1 - De quais códigos o Hibernate está me poupando de escrever?
2 - Quais código a mais o Hibernate me obriga a escrever?
Nem prós nem contras, aqui tem um link meu que faz pensar um pouco sobre o Hibernate tb.
http://mecanicamente.blogspot.com/2007/09/pra-que-orm-se-no-se-usa-oo.html
Miguel, ainda não entedi seu ponto de vista. Você critica o Hibernate (framework) mas defende o Django (outro framework). A discussão não é sobre a real vantagem de utilização de frameworks?
Só resumindo meu ponto de vista, todo software é feito para atender uma necessidade de um cliente. Como ele é desenvolvido determina se o projeto dará lucro ou não. Facilitar as coisas nesta etapa é fundamental. Posso desenvolver o sistema inteiro dentro de uma classe apenas, ou várias classes com dezenas de métodos estáticos. Posso incluir os comandos SQL dentro da apresentação, utilizando o modelo cliente-servidor (software-BD) e ainda deixar a lógica no banco de dados. Posso modelar meu projeto usando OO, dividir as reponsabilidades dos objetos em camadas, deixar o acesso ao BD transparente para a aplicação (ORM), e posso utilizar frameworks neste caso para poupar um tempo precioso de desenvolvimento.
Assim como existem diversas maneiras de desenvolver uma aplicação, existem diversos frameworks para simplificar algumas funcionalidades e devem ser utilizados onde são aplicáveis. Não dá pra generalizar.
O que defendo é que, utilizado corretamente e para os fins a que são destinados, os frameworks aumentam a produtividade e diminuí os riscos de um projeto.
Ronie, estou falando de DAO’s com JDBC para consultas simples.
Miguel,
Duvido que para sistemas do tipo “PoupaTempos do Estado de São Paulo e em sistemas de gerenciamento de empresas de logistica” o Django seja mais fácil de configurar, usar e ainda seja mais eficiente que o Hibernate, mas duvido muito.
Qual a sua opinião sobre uma comparação entre ambos para os tipos de sistema que você mencionou?
E na boa, tudo isto que você falou sobre o Hibernate não procede, eu já trabalhei com sistemas grandes e era o único responsável pela camada de persistência. Nossa base era limpa, usava muito HQL (no more joins nightmares) e quando SQL era necessário ainda sim era ANSI, mudamos de SQL Server para Postgre e HSQL sem praticamente problema algum. (SQLServer em producao e os demais bancos para testes em desenvolvimento).
Hibernate ajudou horrores neste projeto. Agora, eu tive que estudar a coisa? Sim, CLARO, acho que isto faz parte do meu papel com desenvolvedor de software.
Tive problemas no inicio? Sim, mas foi só mapear cada um dos tipos possiveis de relacionamentos que um banco relacional permite e ir depois “copiando” a maneira de configurar as classes.
Agora, eu passei longe de perder minha sanidade mental no processo, foi um desafio como é utilizar qualquer outra ferramenta de desenvolvimento.
Pensar em fazer todo o trabalho braçal de JDBC agora para mim é inimaginável, e como sentir-me perdendo um tempo quebrando pedras, não faz mais o menor sentido.
Realmente pensamos de maneira diferente… Tenho até medo de usar a comparação com o automóvel aqui, pois da última vez até esqueceram que era uma metáfora apenas…
Este não é conceito Miguel, seria o resulta se a ferramenta fosse bem implementada E bem utilizada.
Po Miguel, vc mesmo está dizendo, vc viu exemplos ruins, não confunda o conceito com a implementação!
As colocações do Ronie neste sentido com relação a presença de fallbacks para os casos não previstos fazem muito sentido para os 20~15% que você está comentando.
E de novo, o conceito de você criar um arcabouço para que certos componentes tenham a disposição serviços básicos é tão básica e simples que eu não vejo como criticá-la!
O que é possível sim é que más implementações desta idéia existam, mas a idéia continua igual apesar disto! E pior ainda, existem boas implementações aos montes por ai provando que a idéia pode ser trazida para o mundo real e sim, ajudar muito e vários projetos.
Os frameworks são uma técnica para reutilização de software, definida em termos muito básicos e na minha opinião totalmente coerentes. E por isto e finalmente acho que não faz o menor dos sentidos citar implementações ruins para criticar a idéia, ou ainda implementações sofisticadas que requerem estudo (como é o caso do nosso velho amigo, o Hibernate, afinal, que ferramenta sofisticada não requer estudo?).
Homer,
como eu ja tentei deixar claro aqui, apesar da pergunta inicial ser provocativa, eu nao odeio nem amo frameworks. Gosto de alguns, odeio outros, e o meu primeiro pensamento num projeto não é de colocar frameworks nele, é ver o que eu posso fazer sem.
E vc diz que não dá para generalizar. Mas lá no inicio vc diz que não gostar de frameworks é não aceitar os beneficios. Você está generalizando, como se TODOS trouxessem benefícios.
Bruno,
eu adoraria que você me explicasse o embasamento para duvidar sobre performance de django sobre hibernate. Seria pq um é em Java e outro não? Eu realmente não tenho dados comparativos. Apenas posso te dizer que o site do washington post roda em Django. E sinceramente, não me parece produtivo ficar comparando um com o outro, Java com Python, ou ficar discutindo se o Hibernate é legal. Se vc é feliz com ele, otimo.
Quanto a dizer que o que eu falei em relação ao HIbernate não procede, oks. Pergunte pro Ronnie acima. Pergunte o tempo que ele perdeu pra fazer o Hibernate funcionar. Pergunte pro DBA tambémo tempo que ele perdeu ajustando a base de dados. E pergunte sobre a migração de base de dados. Eu apenas fui espectador deste processo todo.
Homer e Bruno: é engraçado como vcs logo de cara respondem à minha pergunta me atacando como se eu criticasse o conceito. Novamente, eu repito: eu perguntei se os 20% de workaround validam os 80% de repetiçao evitada. Tenham isto em mente.
Vocês deram sua opiniao.
Ok, generalizei mesmo. Nem todos frameworks trazem benefícios. Sua utilização na necessidade adequada é que tráz benefícios.
Só uma pergunta: se fosse tudo construído com JDBC seria mais rápido, menos problemático? Será que a parte trabalhosa não foi no que não era portável (procedures, por exemplo)?
Quanto a pergunta inicial, sem levar em conta fatores técnicos, se o tempo economizado nos 80% com a utlização de frameworks for maior que o tempo necessários com os outros 20% de workaround, o framework ainda é uma boa escolha.
É uma conta simples. Por exemplo: suponha que um projeto sem frameworks consome mil horas de desenvolvimento. Se com a utilização de um framework a construção de 80% do sistema demora metade do tempo, tempos 800 horas construídas em apenas 400 horas. Mas os 20% restantes serão mais demorados, digamos o dobro. Isso resulta em 400 horas para construir as 200 horas restantes. O projeto inteiro foi construído em 800 horas e eu economizei 200 horas. Se a relação de economia-esforço for a mesma, faça sem frameworks mesmo, usando uma equipe mais “barata”, de preferência.
Pergunte a um DBA com 2 ou mais anos de experiência. Ele dirá “duvido que o Django será mais fácil de configurar, usar e ainda mais eficiente que o {Oracle, DB2, Sql Server, PostgreSQL, Firebird}, mas duvido muito.”
A que ponto chegamos? Nenhum.
O outro quer sair pela tangente, separando entre conceito e produto. O meu primeiro texto foi justamente uma crítica ao conceito (o custo de ter que lidar com um framework novo em muitas vezes é superior ao de aprender os subsistemas que compõem o projeto, criam “frameworks” a cada ano e você joga todo seu conhecimento fora a cada ano se quiser ficar adotando tudo que for novo e maravilhoso, etc, etc), o texto do Miguel foi justamente um princípio de discussão com uma idéia nova (de que adianta um framework que me facilita aquilo que eu já sei fazer e provavelmente já posso re-usar de algum outro trabalho anterior, mas não me serve/dificulta para fazer o que eu não sei?), e ainda assim os contrários aparecem com os argumentos do brochure de marketing da Sun.
I need to shut up. I will now.
Só me responda uma coisa: para que foi aberto esta discussão? Vocês já estão com a opinião formada e não há argumentos que vá mudar isso.
Se você não gosta de frameworks, não use então! Aplique seu método “socrático”, implemente tudo na mão! Você será mais feliz.
Eu sou feliz utilizando frameworks (quando preciso), facilitam muito meu trabalho e não tenho problemas de “engessamento” do sistema.
Só pra enfatizar: o que importa é atender a necessidade do cliente. Utilizar frameworks ou não depende da estratégia e maturidade da equipe.
Homer,
note bem: eu propus uma definição de framework e levantei um problema que eu explicitamente coloquei como sendo uma pergunta aberta à comunidade. O que eu esperava? Uma análise crítica dos benefícios ou problemas de um framework, sendo que eu ainda ofereci números a serem discutidos. O Bart deu uma resposta interessante, oferecendo uma solução para eventualmente amenizar os 20%.
Você de cara ja veio com os dois pés no peito falando que tudo isso era papinho de quem tinha medo de novas tecnologias. Só mais pra frente você fez uma conta de horas para justificar o uso ou não de frameworks. Bele…era algo assim que eu esperava.
O engraçado nestas discussões é que eu peço uma reflexão, e logo tornam a questão como sendo algo maniqueista: gosta ou não, e se não gosta vai pro inferno.
Você acima me perguntou do Django, e eu não respondi: eu gosto pq o design permite dele que ele seja usado em vários níveis, e se eu quiser posso usar o mínimo possível apenas para ter alguns poucos serviços básicos. Ele minimiza bem os 20% de uma forma extremamente eficiente.
Aliás, é engraçado perceber que NINGUEM aqui levantou a questão do design da solução. É tão forte a questão de que é heresia discutir frameworks que ninguém veio comentar sobre formas e formas de se criar um.
De modo algum 20% das funcionalidades que agregam valores de negócio são engessadas pela utilização de um framework! Um framework provê um arcabouço estrutural necessário em qualquer projeto, em que muito do código que deveria ser escrito à mão é reaproveitado pela aplicação de um framework.
Se um framework resolve 80% da repetição de código em um software, com certeza os 20% de fallbacks que não são resolvidos por ele são facilitados pela sua utilização!
Frameworks são um ferramental necessário, acredito ser impossível hoje desenvolver um sistema corporativo de grande porte sem ter o devido suporte de um apoio tão importante como de um framework!
É claro que ele não provê auxílio em 100% dos casos, mas imagine ter que atualmente desenvolver uma solução in-house com as funcionalidades providas por ele! Os 20% que ele não agrega em um projeto de software seriam muito maiores sem o seu devido suporte.
Aplicar o devido desacoplamento e injeção de dependências providos por um framework é um bem necessário.
Engraçado como tem tanta gente que não vê isto no Spring…
Mas o maior culpado desta bola não ter sido levantada foi você mesmo Miguel, você começou o post de uma maneira totalmente diferente, claramente discutindo o conceito da coisa e desenhos de implementação.
Hahaha, isto é sair pela tangente???
O que me deixa pasmo até hoje…
Aqui temos um ponto bem interessante, o que você chama de conhecimento é só informação técnica e de fato bem volátil. Conhecimento na nossa área, na minha opinião está mais para paradigmas de modelagem de software, algebra relacional, processo de desenvolvimento, etc. Saber o framework XYZ está longe desta categoria…
Amigo, não é você competindo com o framework para ver quem sabe fazer X ou Y, o fato é: ter um framework bem desenhado que apresente componentes genéricos ao ponto de serem reutilizados e extendidos em diversos pontos.
Hahaha again! material de marketing da Sun?!?! Sorry, não tem como não achar isto engraçado, hehe.
Amigo, que a Sun tem a ver com esta conversa toda??? Deixa eu te dizer que modelagem de software (inclusive soluções como a construção de frameworks acredite) precedem a existencia da empresa, hehe. Só você Raphael….
Bruno, você tem dois jeitos para me calar… o primeiro é continuar com as mesmas respostas e com a ironia. Aí, vou me calar por que não sou estúpido para ficar reciclando discussões e esperando resultados diferentes.
O segundo é você construindo alguma coisa que eu possa admirar, e que mostre o quanto os seus princípios foram importantes para o resultado.
Desculpe Raphael, mas quem falou de material de marketing, formato brochura, da Sun foi você…
Ps. Não é trabalho de um DBA comparar ferramentas como Hibernate ou Django.
Pergunta sincera: e se a empresa tiver um DBA (ou desenvolvedor de DB, chame como quiser) que chegasse e falasse “Essa aplicação que vocês estão desenvolvendo pode ser feita praticamente dentro do banco de dados. O máximo que vocês precisariam trabalhar é na parte de apresentação. Nem precisa de mapeamento O-R.” Considerando que os servidores de banco de dados hoje já tem algum razoável suporte para saída em XML, pq não deixar o trabalho na mão dele?
!!!
Bruno,
vc comenta que acha engraçado que muita gente não as qualidades do Spring. Bom, novamente quero reforçar que NADA, abolutamente NADA no post inicial leva à uma discussão de frameworks Java vs outras linguagens, muito menos à uma análise de Spring, que pelo o que eu mesmo falei em algum lugar aqui, eu conheço muito pouco e que eu sempre ouvi falar bem. E note: o fato de eu achar o Django bom não significa que outros sejam ruins.
Quanto a levantar a bola, eu sei muito bem a bola que eu levantei. E de novo eu digo: logo vieram com dois pes no peito (e continuam vindo) falando que é impossível criticar o conceito e afins. Então tá: se o conceito é intocável, termina aqui a dicussão. Se não existem formas e formas de implementar, termina aqui a discussão. Se levantar uma visão crítica sobre framework recai em discutir sobre Java, ou sobre a suposta impossibilidade de outras linguagens serem eficientes, “escalaveis” e afins, termina aqui a discussão.
Acho que ficar criando e mantendo Dogmas, na área de SW, algo complicado.
E eu ainda não consegui uma visão tua crítica sobre o que eu falei. Em vez de você e o Raphael ficarem na discussao boba, por favor, comente sua visão sobre as porcentagens, os benficios, as estrategias e afins.
Reforçando só mais uma vez: o post inicial foi uma pergunta, PROVOCATIVA, e não uma opinião fechada minha que estou impondo a vocês.
E so relembrando algo que eu escrevi no post, e que deveria mostrar a TODOS que estao falando que é um absurdo eu estar criticando o conceito:
> Eu concordo com estes dois pontos. As porcentagens não são nenhum pouco
> científicas, mas pela minha pouca experiência eu diria que elas são bem
> aceitáveis. E pareceu ser consenso na sala de que estes 80% justificam a
> existência do framework. De certa forma eu também concordo com isso.