Sério, eu até tinha planejado um PodCast sobre framework caseiros e ferramentas miraculosas, mas desisti porque pensei que o mercado meio que tinha amadurecido depois que o meu “Case” do Podcast resolveu chamar um arquiteto para domar a confusão que esse tipo de solução causa.
Eis que uma nova discussão no GUJ me faz pensar que talves ainda seja válido alertar para esse problema que é criar soluções caseiras ou fechadas.
A comunidade Java sofreu muito antimarketing por causa desse tipo de coisa, quem se lembra do Egen sabe do que estou falando, o último que conheço que abandonou o Egen e construiu a aplicação do zero foi a PGE-CE (só que construiu em dotNet). A comunidade JAVA sempre sofreu desse fetiche de gerentes despreparados de quererem resolver a solução por mágica.
Tenho uma fórmula de fracasso para esse tipo de solução, independente se é Framework ou Tool os ítens servem para ambos os casos.
Fórmula para o fracasso:
- Definir uma plataforma de referência (muito comum em órgãos públicos), que sirva para todo e qualquer sistema;
- Usar um framework/tool proprietário na plataforma de referência;
- tool/framework fechado tem comunidade pequena (portanto fonte de pesquisa menor), código geralmente não padronizado, dificuldade de encontrar pessoal que domine a ferramenta, práticas abomináves que tentam concentrar o conhecimento para evitar que a concorrência tenha algo igual
Variação da Fórmula:
- Definir uma plataforma de referência (muito comum em órg]as públicos), que sirva para todo e qualquer sistema;
- Usar um framework/tool proprietário CASEIRO na plataforma de referência;
- tool/framework é desenvolvido “in house”, o que piora o item 2 exponencialmente já que geralmente esse framework foi pensado para um solução específica e depois foi “vendido” como solução para qualquer sistema, desenvolvido por uma equipe que o tinha como meio e não fim (por isso atrasaram o projeto inicial já que além do sistema ainda desenvolveram as ferramentas), a empresa que desenvolve como meio não tem recurso de uma Borland por exemplo e o sistema é cheio de “nas coxas”.
A maioria de quem é senior já passou por isso, eu mesmo já desenvolvi meu próprio framework action-based, aconselho a todos os juniores a fazerem o seu, é uma exercício excelente.
A culpa de deixarem os frameworks caseiros se tornarem oficiais da empresa é dos gerentes/arquitetos que tem a obrigação de saberem que isso é “harmful”, e se deixam, devem perder sua insígnias imediatamente, sinal de que não sabem de nada ou ficaram hibernando na década de 90 e milênio novo.
Eu detesto Struts e tenho minhas críticas ao Model2 por tudo que ele provoca, mas entre escolher um Struts que tem bibliografia extensa, documentação a dar no pau, maturidade, ser livre e aberto, fóruns, pessoal a vontade e inúmeros casos reais… e escolher um framework desses da minha fórmula do fracasso, fico com a primeira opção sem piscar o olho.
[update]
Ah! ia esquecendo, o Shoes blogou sobre a discussão do GUJ.
[/update]
Typically chemist’s shop can sale to you with discreet treatments for various health problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a so complicated problem. Matters, like “coupons for viagra“, are coupled numerous types of health problems. If you need to take prescription medications, ask your dispenser to check your testosterone levels before. Sometimes the treatment options may include erectile dysfunction remedies or a suction device that helps get an hard-on. Keep in mind web-site which is ready to sell erectile disfunction drugs like Viagra without a formula is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.
Já trabalhei com o eGen e não tenho conclusões boas a respeito dele, mas é somente uma opinião minha, pois gosto de ter total controle pelos códigos do meu sistema e que nada externo interfira no mesmo.
Em relação a frameworks caseiros, sem comentários. 🙂
Todos que conheci que já trabalharam com o Egen tem uma opinião negativa sobre ele, mas ele é passado, existme novas roupagens para a mesma idéia, tanto que tem empresa que sai o país inteiro vendendo mágica.
Tempo desses vi uma demonstração de um tal Scriptcase (ou algo assim) feito em PHP e na hora me bateu um “Dejavu” 🙂
Infelizmente ainda tem gente que adora criar frameworks, uma coisa é você criar para aprender, estudos etc, outra é criar juntamente em um projeto grande e crítico, infelizmente temos muito isso, principalmente em órgãos públicos, pois quase não existem gerentes.
O que eu acho que deve ser feito é:
1. Ver o foco e objetivo do projeto
2. Escolher um frameworks maduro e claro de preferência com uma ampla bibliografia.
3. Caso seja necessário “bombar” esse frameworks, ora, se é opensource, tem o código fonte, então altere ele, deixe ele como você quer, se uma determinada ferramenta desse framework não esta te atendendo por completo, ALTERE, você tem o poder para isso, se por algum motivo você não pode ou não quer, coloque outra api menor que resolva seu problema, agora CRIAR do zero algo que já existe, putz, desculpem, É BURRICE.
Já vi casos que uma determinada pessoa colocou os jar do struts na aplicação, mas REFEZ o validator e messagen properties, RIDICULO, sem falar que está usando o projeto como laboratório e reiventando a roda O_o não e isso é estranho e muito amador.
Ótimo post milfont.
Por que tu detesta tanto o Struts? rss, ele é bom e funciona.
Isso não vai mudar, enquanto gerentes cederem “poder” à algum desenvolvedor “sênior” (reparem nas aspas) sem experiência no mercado sempre teremos coisas mirabolantes (ou bizarras).
Pessoal do mundo Java de hoje vive sonhando em desenvolver canhões com os frameworks mais hypes para matar formigas (fazer CRUDs por exemplo) 🙂
Se deixarmos um único carinha desse tipo comandando a estrutura e os padrões de um projeto não haverá outro caminho se não o fracasso.
Quem deveria definir os padrões, ferramentas e estrutura de um projeto deveria ser a equipe como um todo, e não somente um carinha que acabara de sair da faculdade.
Belo post!
Concordo com tudo que foi dito aqui. Essas idéias são muito importantes de lembrar num cenário corporativo, onde o fim da empresa não é desenvolver tecnologia.
Mas ao mesmo tempo me dá uma angústia, pois temos poucos incentivos no desenvolvimento e pesquisa nesse país. Ocorre que uma grande maioria de desenvolvedores querem e acham que é certo apenas ficar utilizando coisas que já existem, e não tentam criar ou evoluir nada. Nesse contexto até é certo! Meros usuários.
Onde estão as empresas e universidades nesse cenário? Quais os grandes frameworks desenvolvidos por univerdiades ou empresa brasileiras? Porque as empresas não investem em pesquisa?
Tudo que é novo sai das pesquisas!
Essa é nossa cultura…
Por isso perdemos nossas maiores mentes, e isso ocorre em várias área.
Parabéns pelo post milfont.
@Fabio
Concordo com você em partes. É claro e evidente que o Brasil é um país pobre e subdesenvolvido, por isso a falta de incentivo a pesquisa é tanta.
Mas existem os guerreiros que conseguem fazer frameworks que conseguem se equiparar a frameworks consagrados no mercado.
Irei citar alguns:
Mentawai
Vraptor
Neo
SwingBean
Spring Annotations
Floggy
Mais informações: http://www.rafaelcarneiro.org/blog/2007/06/22/mais-um-framework-mvc-made-in-brasil/
Eu sei, até conheço o Fabio Kung e uma galera do Vraptor. Mas você mesmo falou: “gerreiros”.
Ainda é pouco!
[]’s
Pingback: Aplicações sérias em JSF usam Facelets | Rafael Ponte
Boa introspecção, mas cuidado: – Imagina se tivessem dito tudo isso para os caras que estava bolando todos esses frameworks que hoje, dominam o mercado? Não esquecem que grandes idéias começaram com discuções como essa: Será que X atende ao nosso propósito? se não, vamos fazer melhor? – Veja apenas uma diferença entre um framework bom e outro ruim: – Ter coragem de evoluir e manter o foco na solução.
Pingback: Frameworks Caseiros 2: A missão - CMilfont Tech
Pingback: Palestra Agilidade no Mundo Real - Milfont Consulting
Acho que Framework próprios não são o fim do mundo. O problema é a empresa não entender que precisa investir para ter algo de qualidade. E investir para sempre!
Framework próprios podem ser uma ótima ideia SE a empresa estiver disposta a GASTAR para mante-lo com qualidade.
Só que isso, sim, é raro como um raio, um avião e um cometa se colidirem ao mesmo tempo.