Frameworks/tools caseiros ou fechados

{ January 20th, 2008 }


cmilfont

Autor: cmilfont

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:

  1. Definir uma plataforma de refer√™ncia (muito comum em √≥rg√£os p√ļblicos), que sirva para todo e qualquer sistema;
  2. Usar um framework/tool proprietário na plataforma de referência;
    1. 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:

  1. Definir uma plataforma de refer√™ncia (muito comum em √≥rg]as p√ļblicos), que sirva para todo e qualquer sistema;
  2. Usar um framework/tool proprietário CASEIRO na plataforma de referência;
    1. 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]

Categories: Engenharia de Software, Frameworks, Java, mercado, Software Livre ~ ~ Trackback


Assine os coment√°rios deste artigo.


12 Responses to “Frameworks/tools caseiros ou fechados”

  1. 1
    Rafael Carneiro

    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. :)

  2. 2
    cmilfont

    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” :)

  3. 3
    Handerson Frota

    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.

  4. 4
    Rafael Ponte

    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!

  5. 5
    Fabio Santiago

    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.

  6. 6
    Rafael Carneiro

    @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/

  7. 7
    Fabio Santiago

    Eu sei, at√© conhe√ßo o Fabio Kung e uma galera do Vraptor. Mas voc√™ mesmo falou: “gerreiros”.

    Ainda é pouco!

    []’s

  8. 8
    Aplica√ß√Ķes s√©rias em JSF usam Facelets | Rafael Ponte

    […] evite reinventar uma roda ainda pior do que as j√° existentes [n√£o quero entrar na discuss√£o dos malef√≠cios de criar seu framework […]

  9. 9
    Davi

    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.

  10. 10
    Frameworks Caseiros 2: A miss√£o - CMilfont Tech

    […] algo em comum: tinham uma arquitetura de refer√™ncia, mais de 4 anos, baseados no struts 1.x, framework caseiro desenvolvido em cima do struts, modica√ß√Ķes caseiras em APIs conhecidas sem contribui√ß√£o com o […]

  11. 11
    Palestra Agilidade no Mundo Real - Milfont Consulting

    […] http://www.milfont.org/tech/2008/01/20/frameworkstools-caseiros-ou-fechados/ http://www.milfont.org/tech/2009/06/06/frameworks-caseiros-2-a-missao/ http://www.milfont.org/tech/2008/01/21/nao-use-notacao-estranha/ […]

  12. 12
    Artur Bernardo

    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.

Leave a Reply