Estilos para Construir Frameworks

Ao longo destes anos pude acompanhar várias equipes envolvidas no desenvolvimento de frameworks – o que é sempre um prazer. Depois de muitas observações, creio que posso tentar delinear alguns padrões de comportamento destes arquitetos envolvidos nestes projetos.

O primeiro estilo, e o mais freqüente, é o “bottom-up”. Estas equipes são extremamente focadas em tecnologia e muito preocupadas em trazer o que há de melhor delas. Muitas vezes, ficam excitados com a grande onda de inovações que vêem de fora – novas bibliotecas, frameworks e linguagens – e correm em busca da atualização constante antes mesmo de terem seu trabalho pronto e em uso. Uma boa parte dos frameworks destas equipes é considerada complexa pelos seus usuários e, com alguma freqüência, seus frameworks caem em desuso. Quando isto acontece, estes arquitetos costumam culpar o mal preparo dos profissionais de mercado pela baixa produtividade ou incompreensão.

Um segundo estilo, é o que advém de um framework não planejado. Um conjunto de funções e classes facilitadoras que foram se criando ao longo do tempo e que viram parte da cultura da empresa. Com a vantagem de trazer rapidamente resultados, este estilo não pretende e não consegue maximizar o reuso, perdendo, muitas vezes boas oportunidades de melhoria na produtividade do seu time ou desempenho de suas aplicações.

Tendo, eu mesmo, ao longo do tempo, experimentado estes estilos, hoje sou um proponente de uma terceira variante. Começo sempre trabalhando com minha equipe programando como se fossemos o programador da produção, mas em cima de um framework imaginário – aquele que um dia faremos. Nesta fase, nos preocupamos mais com qual seria o impacto visível, para o programador final, da introdução das várias capacidades cross-cutting que o framework futuro deverá lidar: como autenticação, autorização, sessão, caching, etc. Uma vez definida a forma de programar, mostramos estes programas fictícios aos programadores de facto (nossos usuários finais) e ouvimos suas críticas. Com as críticas, retornamos ao modelo de programação para trazer uma nova proposta, continuando este ciclo até que todos estejam satisfeitos.

O passo seguinte é desenhar o framework que implemente aquele modelo de programação negociado.

Um assunto para meu próximo blog.