Quando uma empresa investe tempo e mão de obra para desenvolver algum framework para seu uso próprio, ou até mesmo minimizar a complexidade da utilização de outros, significa que o nível de maturidade em uma determinada tecnologia se elevou ao ponto tornar o processo de desenvolvimento, com o uso dessa tal tecnologia, mais ágil.
Estratégias utilizadas para obter essa flexibilidade variam dês de desenvolver templates, classes abstratas, soluções que utilizam padrões de projetos que visam a reutilização, desenvolver forks de frameworks open source para se adequarem ao modelo de desenvolvimento da empresa. Essas alternativas visam poupar tempo com situações de um cadastro simples, persistência auditada, autenticação, etc.
Estratégias como essas vieram a tona nos tempos do Struts e dos EJBs 2.*, já que era notável a necessidade de eliminar os detalhes de implementação do struts (forms, templates, actions customizadas, autenticação, acesso a recursos de serviços distribuídos, etc). Já os EJBs, mesmo em versões antigas, demonstram robustez, confiabilidade e segurança para as aplicações corporativas. Daí veio os patterns J2EE, XDoclets com a finalidade de integrá-los e diminuir, pelo menos um pouco, o grau de acoplamento entre os serviços. Com isso, a estratégia de diminuir o tempo de desenvolvimento seria válido devido a complexidade dessas tecnologias e da grande quantidade de arquivos XML necessário para configurá-los.
Essas tecnologias sobreviveram até hoje e ainda recebem manutenção de empresas que as tem como base de seus serviços. É justificável, pois muitos recursos investidos para o aprimoramento dessas ferramentas geralmente são altos e algumas vezes são peças-chave em vários projetos. Na maioria das vezes, principalmente em projetos com particularidades específicas, as soluções desenvolvidas para o mesmo geralmente tornam-se parte do framework da empresa para, caso necessite, ser utilizada em projetos futuros, fazendo o framework “inchar”.
Vendo esses problemas agora vem uma pergunta no ar: Mas porque cargas d’água fizeram essa joça? Porque deixaram isso acontecer? Ninguém previu isso? Eu também queria a resposta para essas perguntas, porém, muitos fatores podem ter ajudado a formar essa bola de neve; falta de experiência da equipe, má vontade, individualismo, falta de visão. Quem já trabalhou ou trabalha em corporações que tem essa mentalidade sabe do que eu estou falando. É nesse ponto que a compreensão dos pilares que a empresa dispõe para o desenvolvimento de seus projetos.
Quando uma empresa estabelece um pilar sua base deve ser rígida. A rigidez significa aceitar a evolução constante do código e ao mesmo tempo das libs, frameworks e JVMs que serão utilizadas futuramente nos projetos da empresa. Caso isso não aconteça, a base do pilar não suportará a evolução do framework podendo até se quebrar. Com isso, os bugs nos projetos que utilizam uma infra-instrutora arcaica vêm a tona. Quem trabalha especificamente com Java deve ter experiência com essa abordagem.
Uma boa equipe, sendo bem gerenciada, desenvolveria um framework que fosse, no mínimo, flexível. De forma que suporta, no mínimo, atualizações de bibliotecas intermediárias assim como atualizações da JVM, já que está sempre em constante evolução e cada momento seu desempenho está sendo sempre incrementado. Acredito que medidas simples tornariam a infra-estrutural de uma empresa evoluindo corretamente e principalmente independente de framework.
Isso é possível de fazer? Sim! Existem provas? Sim e são bem claras. É possível encontrar isso constantemente em projetos open source. M uma simples lida nos changelogs é possível ver a constante atualização de bibliotecas do projeto, substituição de jars e suas adaptações conforme as mudanças. Isso é um pouco trabalhoso porem recompensável, pois a base do pilar fica cada vez mais forte.
A linguagem Java, juntamente com a JVM, está em constante evolução. Desenvolver projetos (ou frameworks) fadados a utilizar uma versão específica da JVM é desperdício de tempo. Projetos como esses dificilmente suportarão a evolução, a longo prazo, de seus elementos fundamentais (JVM e frameworks). As mudanças ficarão restritas apenas a uma versão específica de sua estrutura, portanto caso cresça muito o pilar irá se partir.
[]s
No Comments » 