Olá pessoal, tudo certo?

Eis que o assunto ressurge: desafios na construção de frameworks.

Não é de hoje que o mercado tem tratado esse assunto. O tema é realmente importante, tanto pelas oportunidades de acertos como pelos erros, que muitas vezes podem ter um grande impacto na arquitetura e no negócio da empresa. E durante uma conversa com outro arquiteto, sr. Nakajima :), revi alguns conceitos que agora comento com vocês. Mas não pretendo esgotar aqui o assunto, apenas repassar alguns aspectos importantes que podem gerar novas discussões com sua equipe.

Para uma definição mais formal, vamos dizer que um framework pode ser visto como um padrão de arquitetura, o qual pode ser criado utilizando-se uma linguagem de padrões de projeto. Sua modelagem reflete uma infra-estrutura reutilizável e adaptável a algum contexto. E pensando em contextos, podemos identificar dois tipos: frameworks horizontais e frameworks verticais.

• Os frameworks horizontais são aqueles voltados para domínios gerais de aplicações, de uso geral, como ODBC, o próprio .NET Framework, MFC - Microsoft Foundation Class, entre outros conhecidos;
• Já os frameworks verticais são aqueles voltados para um domínio específico de aplicações, atendendo cenários dedicados, como mercado financeiro, aplicações de helpdesk, soluções específicas para aplicações de bilhetagem em telefonia, etc. Ou seja, são frameworks com grande foco num nicho específico de aplicações.

Desse modo, frameworks atendem naturezas de aplicações muito diferentes. Note que essa classificação irá determinar ainda outras necessidades, como performance, latência, manutenção, frequência de versionamento, dimensionamento de camadas, modelo de segurança, tratamento de exceções, aderência ao balanceamento de carga, etc.

Mas quase sempre, o foco básico de um framework é o reuso de um bom modelo de programação ou o encapsulamento de um bom código que faz uso ou disponibiliza recursos importante da empresa. Em algum momento, a empresa deseja implementar um framework que faça o acesso a um banco de dados, classes de monitoração, auditoria, controle de acesso, autorização, autenticação, etc.

De um modo geral, existem muitos benefícios prometidos com o uso de um framework, como:

• Maior produtividade;
• Maior qualidade do software gerado;
• Redução de escopo;
• Redução do prazo de entrega;
• Redução da quantidade de linhas de código;
• Padronização e manutenção facilitada;
• Aplicação de padrões adotados;
• Reuso de arquitetura, patterns e código;
• Utilização de soluções prontas e testadas;

Realmente, a idéia é reaproveitar peças de código que já foram intensamente testadas e que apresentam um comportamento conhecido e desejado para a aplicação, minimizando assim situações de quebra, falhas de lógica, permitindo uma depuração mais amigável.

Porém, podemos citar vários fatores de resistência ao framework ou seu desenvolvimento dentro da empresa, como:

• Resistência organizacional, diante da construção do framework ou mesmo seu uso;
• Resistência gerencial, devido a competição por recursos, pessoas, cronogramas;
• Resistência dos desenvolvedores que irão usar o framework, depois de pronto;
• Questionamentos sobre o retorno do investimento e impacto real de benefícios;
• Ausência de equipe capacitada para participação no núcleo de desenvolvimento principal do framework;
• Ausência de um plano claro e objetivo para a adoção e implantação do framework em produção;
• Clara visão sobre o tempo para o retorno do investimento realizado.

Também é importante que o framework em desenvolvimento contemple as melhores práticas e código de alta qualidade, para que ele mesmo seja um facilitador de recursos e não motivo de problemas para as aplicações que fazem seu uso. Veja como essa condição é crítica para o sucesso de um framework.

Assim, alguns aspectos importantes para um bom projeto de framework são:

• A construção do framework deve ser considerada estratégica para a área de TI ou a área responsável. Sem essa orientação, é possível que o projeto se perca pelo caminho;
• Deve haver um forte patrocínio e um compromisso gerencial nessa atividade;
• Deve haver uma conscientização e um trabalho de divulgação durante seu desenvolvimento. O envolvimento de vários departamentos da empresa é difícil, mas crítico para uma rápida adoção do projeto;
• Deve haver um plano de comunicação e colaboração entre equipes participantes e usuárias do framework;
• O processo de desenvolvimento deve ser retro-alimentado, para se garantir adaptações e correções de rotas em tempo;
• Deve haver um compromisso da liderança do produto e da equipe de desenvolvimento com a missão do framework;
• Finalmente, a equipe de desenvolvimento do framework deve ser sênior e capacitada para tal.

Tratamos até este ponto de aspectos mais gerenciais do que técnicos, não é mesmo? E como fica a codificação do framework? Como implementar? Quais modelos de camadas, classes ou arquiteturas são mais indicadas? Aqui entra a leitura e o contato com bons exemplos de frameworks e código que o arquiteto deve procurar conhecer.

Os últimos posts falaram muito de WCF - Windows Communication Foundation e como sua estrutura configurável e extensível permite soluções com grande performance. Outro aspecto que vale citar é sobre sua estrutura interna. Sendo altamente configurável, o WCF é um excelente exemplo de framework que podemos estudar e entender para a construção de nossos próprios frameworks. Recomendo a leitura de bons livros e artigos tratando da estrutura interna do WCF, como:

Channel Model Overview
http://msdn2.microsoft.com/en-us/library/ms729840.aspx

A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies
http://msdn2.microsoft.com/en-us/library/bb310550.aspx

Vale ainda olhar artigos sobre estruturas ou mesmo direções de tecnologias para a definição de um framework. Por exemplo, em 2005 podíamos usar um artigo como esse abaixo para entender a visão do .NET Framework e seus componentes (ainda hoje sua leitura é válida):

Building Connected Systems: The .NET Framework and the Microsoft Enterprise Application Development Platform
http://msdn2.microsoft.com/en-us/library/ms973223.aspx

Ou seja, para a construção ou adoção de um framework, devemos entender muito bem as necessidades reais de nossas aplicações, assim como as tecnologias disponíveis que podemos utilizar para a melhor implementação de solução de um framework. Sempre lembrando que, antes mesmo de iniciar a construção de um framework e encarar todos os desafios citados acima, talvez seja interessante identificar um framework já existente no mercado que possa atender nossas necessidades.

Outro aspecto que vale uma discussão é sobre a disciplina de desenvolvimento, ou o chamado Application Lifecicle Management (ALM) e como será feito o gerenciamento do projeto do próprio framework. E no caminho para a reutilização de software, a busca contínua pela produtividade, vale ainda conhecer a estratégia para Software Factories que temos publicada no link...

Software Factories
http://msdn2.microsoft.com/en-us/teamsystem/aa718951.aspx

...pois pensar na geração automática de código, que referencia ou não um framework existente, é uma tarefa importante para a produtividade no desenvolvimento de software.

Como disse, o assunto não se esgota por aqui. Em posts futuros pretendo discutir alguns exemplos práticos de frameworks, implementações de referências e estruturas que podem nos ajudar na construção de frameworks, quando realmente necessários.

Por enquanto é só. Até o próximo post! :)

Waldemir.