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]
Posted in Engenharia de Software, Frameworks, Java, Software Livre, mercado ~ 8 Comments
OPML Completo.
Texto Completo