A primeira base que temos que adotar para a construção de um framework corporativo é o valor ao desenvolvimento, ou seja, o quanto esse componente agrega ao processo de criação de software. Em linhas gerais, posso resumir isso em quanto a solução proposta pelo framework se adequa ao problema da equipe de desenvolvimento e de quanto dinheiro é economizado com o seu uso.
Um dos primeiros erros ao se decidir criar um framework corporativo é começar com a solução, e não com o problema a ser resolvido. Nos achamos superiores ao imaginar que conseguimos criar uma bala-de-prata que irá matar um lobisomem que ainda nem existe (e nem sabemos se será um lobisomem ou outro tipo de monstro). Já vi projetos de ERP em que antes de se ter requisitos de negócio já se estava codificando uma biblioteca de componentes utilitários ao projeto. Não! Vamos entender melhor primeiro o que precisa ser resolvido, e focar no problema e não em criar o componente mais bonito do mundo cuja maior parte (senão todo) não é utilizado. Com os requisitos mais bem definidos, podemos olhar para o mercado e ver se já não existe uma opção pronta e que seja viável tecnicamente e financeiramente.
Além disso, é preciso estar aderente às estratégias de crescimento da empresa (papel do arquiteto), pois de nada adianta as horas gastas se mais para frente todo o trabalho se torna obsoleto (por exemplo gastar esforço em um framework de aplicações desktop sendo que o direcionamento da empresa é ter seus sistemas em web). Por outro lado, precisamos ter um compromentimento da parte dos gestores (gerentes, diretores, etc.) em ter recursos alocados para a evolução e continuidade do que foi feito.
Um último detalhe. Precisamos saber vender o framework construído para outras equipes. Somos os fornecedores deles, e eles não estão fazendo nenhum favor em utilizar o que criamos. Reitero, temos que agregar valor para os outros (TI é sempre assim, trabalhar para suportar o trabalho de outras pessoas).
Decidimos que temos que criar um framework corporativo. Ótimo, vamos colocar a mão na massa. Criamos uma primeira versão do componente que atenda uma equipe de sistema X. Fazemos um happy hour para comemorar o uso com sucesso dessa equipe. Outro time Y vê e também quer utilizar o framework, mas o problema que eles têm para resolver é um pouco diferente do primeiro. Vamos ter que alterar nossa recém-criado ferramenta… e agora, é fácil? Podemos sair mexendo? E se quebrarmos alguma coisa que a primeira equipe usava?
Aqui destaco a maturidade, comprometimento e grande conhecimento que as pessoas que constrõem esse tipo de software devem ter. Precisamos de um framework que possa ser adaptador para novas situações de forma fácil! Precisamos de componentes que tenham contratos de uso bem definidos! Não estou falando nenhum conceito fora do comum, é a pura aplicação da orientação a objetos e as boas práticas associadas (isolamento dos detalhes da implementação; princípio Open/Closed – código que permite extensão mas é fechado para modificação, etc.).
A idéia aqui não é ter um BDUF (Big Design Up Front, ou seja, tentar prever todos os problemas e já contemplar a solução logo de primeira), mas precisamos usar nossa experiência para que pelo menos os problemas que já passamos na vida possam ser endereçados de uma forma mais elegante e de fácil manutenção.
Outro ponto importante: o nosso framework precisa ter uma fácil distribuição e minima dependência de outros componentes. Isso facilita quando temos que distribuí-lo para uso de outras pessoas, como fornecedores externos (fábrica de software).
Para este caso, tenho uma experiência feliz. Cuidávamos de um framework de processamento assíncrono, que funciona da seguinte forma: um sistema possui um componente .NET no COM+ (sim, COM+, legado…); ao invés da parte cliente desse sistema chamar este componente diretamente, ele acionava nosso framework, passando o nome do componente deles, o nome do método e os valores dos seus parâmetros para a execução, e nosso componente enfileirava a execução e colocava para rodar assím que possível. Uma vez identificamos um problema neste framework, que segurava referência de dll .NET quando era passado um parâmetro de tipo definido pelo cliente (que não fazia parte dos tipos do CLR). Quando era necessário atualizar o sistema, não era possível mexer na dll. O ponto de problema era a manipulação do objeto contendo as informações do que seria executado diretamente pelos clientes do framework. Com o simples uso de poliformismo, fizemos a alteração no sistema de forma a tratar este caso sem quebrar o contrato dos vários sistemas que utilizavam nosso framework. Este foi um ponto legal, pois era inviável o retrabalho das muitas equipes de sistema em adaptar o uso caso fosse necessário mudar a forma como se utilizava o framework.
Temos vários níveis de experiência dos desenvolvedores dentro de uma empresa, desde o mais escovador de bits até o que ainda não sabe ligar um computador (sim, eles existem e provavelmente hoje ganham mais que o seu pai ganhava quando trabalhava para sustentar você). Vou citar um caso. Há algum tempo introduzimos um framework para desenvolvimento web ASP.NET, uma moldura (uma master page, para ser mais exato) na qual as demais equipes de sistemas colocavam suas páginas. O ganho principal neste caso eram controles já embutidos na solução (menus, controle de acesso, etc.), e uma certa padronização visual. De repente, começamos a receber reclamações que este framework não funcionava direito, e estava atrapalhando o desenvolvimento das equipes. Ao analisar melhor o caso, descobrimos que na verdade o erro que os desenvolvedores estavam tendo na chamada aos seus próprios serviços WCF, por falta de conhecimento desse framework da Microsot. Mas como eles não sabiam interpretar os erros, acabavam tomando por verdade que a causa dos seus problemas era o famigerado framework. E eis que surge a famosa “muleta”. Tivemos que parar o que estávamos fazendo e provar por A mais B que o erro era com eles. Para ajudar, o coordenador dessa equipe não tinha competência técnica para entender o problema, e comprava a briga deles sem conseguir compreender que o erro estava com eles. Infelizmente (e é muito difícil para mim falar isso), temos que aceitar a realidade que hoje trabalharemos com muitas pessoas que vão deixar a desejar no quesito de conhecimento, principalmente porque atualmente o mercado de TI está aquecido e dá bons salários para pessoas que não têm muito estudo ou aptidão para a coisa.