Considerações sobre frameworks corporativos

Um dos objetivos mais desejados pelos gerentes no desafio de desenvolver sistemas é a reutilização de componentes com a finalidade de economizar trabalho e tempo (ou seja, dinheiro). Com essa idéia na cabeça e uma boa dose de boa vontade, os desenvolvedores e arquitetos procuram criar ferramentas e componentes que possam ser compartilhados dentro da corporação (frameworks técnicos). Em muitos casos, apesar do esforço, esse objetivo não é alcançado, e acabamos citando o ditado “de boas intenções o inferno está cheio”…

Não estou dizendo que a reutilização é um conceito ruim, ao contrário, é claro para a indústria de software prova a necessidade e importancia dela a cada dia. No entanto, gostaria de compartilhar as minhas experiências em relação à esse assunto para ajudar a evitar as armadilhas que aparecem quando decidimos criar um framework corporativo. Trabalhei bastante tempo criando e mantendo esse tipo de software, e acho que tenho algumas boas histórias…

Separei três principais bases na qual um framework corporativo deve se basear, e consequentemente quais são os problemas que geralmente encontramos caso esses pré-requisitos não sejam seguidos.

A ferramenta certa para o problema errado

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).

Como enfrentar as mudanças?

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.

Conhecimento é a chave

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.

O que aprendemos aqui é que um framework corporativos precisam ser de fácil utilização, com mensagens claras de erros que ocorram, sejam eles por uma configuração/uso incorreto pelo desenvolvedor, ou pelo próprio código do desenvolvedor. Em uma outra situação, num framework corporativo para acesso a base de dados SQL Server, vimos que simplesmente colocando um tratamento de erro mais claro (mostrando detalhes do erro, qual base de dados, servidor, etc.) a quantidade de reclamações sobre a qualidade do framework caiu drasticamente, pois os próprios desenvolvedores conseguiam identificar e resolver os problemas.

Mas mesmo assim, é essencial que haja treinamento contínuo da ferramenta. Uma boa documentação com exemplos práticos é essencial. Indo mais fundo, entendo que seja necessário uma equipe dedicada ao suporte aos desenvolvedores, tirando esta tarefa de quem cria e mantém o framework. Se o framework seja utilizado por fornecedores externos, é necessário que haja um ponto focal desse fornecedor para o suporte. As responsabilidades precisam estar muito bem definidas e clara para todos.

E ae, vamos construir um framework?

Na real? Eu estou fora dessa, rs. Acho que hoje estou meio que parecido com veteranos de guerra que qualquer barulho no quintal de casa já acham que são vietcongs. Talvez eu mude de idéia se todos os pontos de problema que eu apresentei acima sejam devidamente endereçados, principalemte na questão do treinamento (esse foi nosso principal calcanhar de Aquiles)…

Mesmo porque acredito que já exista no mercado uma boa solução para todos os tipos de problemas que geralmente encontramos no desenvolvimento de sistemas. Não precisamos criar algo novo. Volto no ponto que disse que precisamos agragar valor na criação de software, mesmo que isso signifique que não vamos desenvolver nada. Manter um framework corporativo é caro, e é preciso muita certeza de que ele é realmente necessário.

Termino o post com mais um ponto de atenção que não coloquei anteriormente: a cultura da empresa. Se a cultura da empresa for contratar pessoas com nível de conhecimento extremamente distinto (gente muito boa e gente muito ruim tecnicamente) e não prover um crescimento profissional, aí é que o barco afunda de vez. Provavelmente a estratégia dela é querer que as pessoas boas sejam “gurus” que preparem o processo de desenvolvimento de forma que qualquer um (a mão-de-obra “barata” e “facilmente substituível”) possa desenvolver. A tendência é que toda a responsabilidade de qualquer problema caia sobre a equipe sênior, pois é dela a tarefa de prever todo e qualquer erro que alguém possa cometer e não deixá-lo acontecer (já ouvi um coordenador de desenvolvimento tentar isentar a culpa da sua equipe de juniores pois eles “ganhavam muito pouco para poder saber programar direito”). Construir um framework numa empresa assim é um tiro no pé.

Esse foi um resumo das minhas experiências nesta questão, e espero que sejam úteis para alguém.

[]’s