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.

Comments

• Anonymous
  December 06, 2008
  Olá Otávio, Uma coisa que vejo com alguma frequência é a tentativa de criar frameworks de negócio, e não de atividades cross-cutting, como você propôs, ou de infra-estrutura. Acredito que essas duas são as necessidades principais que um framework deve atender. E muitas vezes um framework de negócio acaba errando no nível de profundidade (ou é muito superficial ou demasiadamente carregado de informação), e também de complexidade. É engraçado uma empresa acreditar que um componente que tem um método "ObterClientePorId" vai servir para todas as aplicações que ela vai construir. Algumas vestiram esse tipo de framework com algumas capacidades de SOA, para deixar ele mais com cara de novidade, mas em ambos os casos eles acabam morrendo na praia... a aplicação que deveria utilizá-lo em geral precisa de alguma coisa a mais... []s

• Anonymous
  December 10, 2008
  Otávio, O conheci a muito tempo atrás quando tive a oportunidade dada pela MS de que você pudesse avaliar o software. De la pra cá muita coisa mudou em uma biblioteca com SQLs escritos concatenados por StringBuilder e agora estamos com DataSets tipados e usando bem mais a potencialidade do .Net Framework. O que ainda me pergunto é se em alguns casos, ter um code generator não torna a aplicação mais analisavel do ponto de vista de impactos futuros. Ao desenvolver um framework deve-se levar em conta, sem exageiros, fatores que ainda nem se tem conhecimento pois nunca temos uma visão 100% de um projeto, especialmente o meu que vive de alterações forçadas por legislação. Heranças e Reflextions... ou codigo gerado ?? é uma duvida complexa pq um bom gerador de código (em uma biblioteca não tão engessada) me parece tornar um framework mais flexivel. att, Nilton Nodari nnodari@hotmail.com

• Anonymous
  December 10, 2008
  Salve, Nilton. Minha opinião? Temos uma hierarquia aqui. Boas bibliotenas no nível mais baixo, um bom framework no nível intermediário, componentes visuais e templates que complementam e se apoiam neste framework e, ao final, DSL's e geradores de código para aumentar ainda mais a produtividade. (note que construímos de baixo para cima, mas meu ponto aqui é que desenhamos de cima para baixo, levando em conta o como o programador irá usar o framework - se não estiver legível e produtivo para ele, menos kudos para o framework) É importante que o gerador de código não gere muitas linhas incompreensíveis. Alguém algum dia vai ter que dar manutenção nisto e, portanto, o código deve ser legível. Concordo que não sabemos 100% do que nossos programas irão pedir da nossa infra-estrutura. Daí a idéia de projetar frameworks extensíveis e estar atento para, em algumas ocasiões, aprimorá-lo ou simplesmente não usá-lo. Creio que estamos de acordo aqui, não estamos? Abraços, Otavio

• Anonymous
  December 17, 2008
  Poucos dias atrás o Waldemir me comentou que não achou muito clara a minha proposta de abordagem de framework