Arquivo de janeiro \27\UTC 2010

Log de Negócio

Esta semana tive uma necessidade de log específica em um de nossos sistemas, que acabou gerando uma excelente adição para o nosso framework de desenvolvimento. A necessidade era saber o que acontecia em produção que acabava gerando um bug raro de valores no final do dia, e que fomos incapazes de reproduzir mesmo com uma grande quantidade de testes unitários. Aparentemente o bug está associado a uma condição de multi-usuário que é muito complicada de reproduzir. Para resolver este bug precisaríamos saber a seqüência exata em que as operações foram realizadas, e isto só seria possível com log.

A necessidade de log de negócio acaba surgindo vez por outra em aplicações. E, praticamente para cada sistema que eu já participei, foi feita uma solução diferente para log, com vantagens e desvantagens. Alguns usam log em banco, colocando triggers nas tabelas e replicando as informações, o que é extremamente simples de fazer mas gera grandes problemas de contenção e espaço utilizado. Outros usam versões do log4net gerando dados em arquivos, o que também é relativamente simples de fazer porém gera também dificuldade em ambientes massivamente multi-usuário – sem falar na dificuldade de processar os arquivos depois. Já fiz também log em banco, com e sem log4net, com bons resultados, mas sempre com uma solução específica para cada caso, o que causava um bom esforço de manutenção.

Outro ponto que sempre me incomodou é a questão da intrusividade das funções de log na regra de negócio. Tirando a solução em trigger de banco, qualquer implementação de log4net foi sempre feita com chamadas específicas de log dentro da rotina de negócio. Isto polui a rotina e dificulta a manutenção. Eu sempre tentei criar algo tipo AOP, mas nunca consegui uma solução boa. Mesmo atualmente, as bibliotecas conhecidas de AOP (PostSharp, Spring.Net etc.) não são uma boa opção para o nosso ambiente por serem um framework completo, de grande impacto…. Usar qualquer uma delas só pra log de algumas regras de negócio pra mim seria usar um canhão pra matar uma mosca.

Assim, resolvemos desta vez fazer algo decente, já incorporado ao framework, e que usasse uma abordagem AOP na medida do possível. Graças à tecnologia do Castle Windsor IoC usada atualmente no framework, isto foi relativamente simples de ser feito. Definimos na nossa arquitetura que o log de uma regra deveria ser expresso através da observação de parâmetros e retornos da função, antes e depois dela ser executada. Através do uso destas condições pré e pós, é possível identificar exatamente como aquela função afetou os dados.

Para implementar, o que fizemos foi usar o log4net para salvar eventos em banco. Até aí, solução padrão. O passo seguinte foi definir atributos AOP para marcar uma regra de negócio como sendo logada. O ideal teria sido definir as condições pré e pós no próprio atributo, porém o C# atualmente não suporta nada que não seja estático nos atributos; e usar strings eu acho uma prática ruim. A solução usada foi definir um tipo para o atributo que apontasse para uma classe que definiria quais são todas as condições, utilizando lambda.

O resultado ficou excelente. Abaixo está um exemplo do atributo na regra de negócio:

[Log(typeof(AtualizarValorDePosicaoLog))]
public void AtualizarValorAnterioDePosicao(Contrato contrato, 
                                    Posicao posicao, decimal valor) {
 

E no tipo de definição das condições, fica assim:

public class AtualizarValorDePosicaoLog : LoggerBase {

  public AtualizarValorDePosicaoLog() : base(
    Properties.PreCondition("valor"),
    Properties.PreCondition<Contrato>(
      c => c.Id, c => c.Tipo, c => c.TipoBacen, 
      c => c.Moeda, c => c.Posto, c => c.ValorMoedaEstrangeira, 
      c => c.ValorMoedaNacional, c => c.ValorUSD, c => c.TipoPagamento),
    Properties.PreCondition<Posicao>(
      p => p.Id, p => p.ValorPosicaoAnterior, p => p.Conformidade, 
      p => p.Baixa, p => p.Transferencias, 
      p => p.TotalCompra, p => p.TotalVenda, p => p.Moeda, p => p.Posto, 
      p => p.Tipo),

    Properties.PostCondition<Posicao>(
      p => p.Id, p => p.ValorPosicaoAnterior, p => p.Conformidade, 
      p => p.Baixa, p => p.Transferencias, 
      p => p.TotalCompra, p => p.TotalVenda, p => p.Moeda, p => p.Posto, 
      p => p.Tipo)) { }
    }
 

Na execução, o interceptor da classe de serviço busca o atributo, instancia o tipo de definição e coleta os dados, antes e depois da rotina executar. Para minimizar o impacto em tempo de execução, o logger simplesmente armazena um dicionário com todas as condições recolhidas, serializando num XML. Posteriormente, de maneira assíncrona e com baixa prioridade, um executor analisa os registros de log gerados e expande cada condição em tabelas do tipo dicionário.

Com isto o impacto ficou bem pequeno e conseguimos fazer algo quase puramente AOP e sem nenhuma definição em string! Finalmente conseguimos uma implementação boa para log, que deve nos atender por muito tempo.

Nesta solução, alem da equipe da WhiteFox, tivemos a colaboração do arquiteto Fernando Bichara, da Perlink.

, , , , ,

4 Comentários

Refatorando Grandes Sistemas

Olá, feliz 2010! Eu estou muito animado, as perspectivas para 2010 são muito boas! Fiquei agradavelmente surpreso com a reação das pessoas à White Fox, ela foi muito bem recebida e recebi várias mensagens de apoio, obrigado! Estou muito convicto de estar no caminho certo e construindo uma empresa que será um local excepcional para se trabalhar e prosperar. E o ano começa animado, este mês estamos entregando 2 primeiras versões de novos sistemas além de continuarmos com a manutenção dos existentes.

Conversando com um amigo na semana passada, caímos no assunto de grandes sistemas e do processo necessário à manutenção (evolutiva ou corretiva) para sistemas de grande porte em geral. O que me levou a refletir sobre isto pois, apesar de achar que processos e especialização por segmentos (silos) no desenvolvimento de software seja algo nocivo, não consegui achar nada de errado ou que eu faria diferente naquele caso específico.

O ponto é que grandes sistemas necessariamente exigem uma grande infra-estrutura. Por menor que seja uma mudança, para se garantir que um sistema não seja afetado por ela, é necessário avaliar todo o impacto, preparar uma sequência de testes específicos para a mudança e executar todo o conjunto de testes de integração e funcionais – muitos dos quais, até pelo volume, podem não ser totalmente automatizados. Isto sem falar no processo de liberação de versão em si, que envolve muitas vezes compilações e execuções de testes unitários que podem demorar várias horas. Em um time agile, mesmo com o máximo de automatização, este processo todo iria significar que o time iria passar a menor parte do tempo implementando a mudança e a maior parte do tempo, planejando, testando, integrando e verificando se tudo ficou ok. Não é algo viável, na minha visão. Acho que é por isto que o pessoal de Scrum afirma que Scrum é para novos projetos somente, não sendo adequado para manutenções.

Então o que fazer? Será que para grandes sistemas não é possível usar métodos ágeis? Ou que temos que assumir que para grandes sistemas, irão existir silos (testes e/ou gestão de configuração, por exemplo) e que isto é algo que não tem solução? Os que me conhecem sabem que esta resposta não é satisfatória pra mim. Porém, uma vez que o sistema tenha um certo tamanho, não consigo ver como fazer as coisas diferentes. Talvez então a saída seja não deixar os sistemas passarem de um tamanho crítico.

Claro que certas áreas exigem software de grande porte. O caso de um sistema operacional como o Windows, um aplicativo como o SAP ou mesmo um aplicativo como o Word, são sistemas que irão exigir toda uma infra-estrutura pesada para permitir manutenção e evolução. Não é à toa que o processo de testes da Microsoft, por exemplo, é algo extenso e complicado. Porém, não acho que isto deva ser usado para software de menor porte. Aliás, acho justamente o contrário, usar este tipo de técnica/processo para software de menor porte significa aumentar em ordens de grandeza o custo para desenvolvimento/manutenção e dificultar significativamente o uso de metodologias ágeis.

Assim, quando possível, acho que devíamos buscar quebrar grandes sistemas em aplicações menores. Usando os mesmos princípios aplicados em refatoração de código (tais como responsabilidade única, baixo acoplamento etc.), poderíamos tentar quebrar os sistemas em módulos para que, apesar de funcionarem em conjunto, sejam entidades separadas. Isto seria possível com uma definição clara de fronteiras, com o apoio de interfaces de serviços (SOA) e com um isolamento de interfaces com o usuário. Áreas de negócio distintas poderiam ser separadas de maneira que o domínio de negócio fosse separado, fazendo com que mudanças em um determinado setor do domínio não afetasse os demais. E mudanças na interface de serviços poderiam ser feitas de maneira versionada e evolutiva, no formato tipicamente usado em SOA.

Claro que uma refatoração de sistema só é possível com a participação direta do cliente, já que isto significa por si só uma mudança em processos, modo de trabalho e até mesmo na relação comercial, já que diversos módulos podem também significar mais de um fornecedor. Mas acredito que se isto gerar uma economia significativa no custo de desenvolvimento, será algo que terá grandes chances de ser adotado pelo cliente. O que mais uma vez ressalta a importância da área de contato com o cliente deter também todo o conhecimento técnico para propor e justificar mudanças como esta. Uma área puramente comercial teria muitas dificuldades em entender e vender algo deste tipo. Felizmente este não é o caso da White Fox.

Na White Fox nós temos alguns sistemas que estão começando a entrar no estágio em que a manutenção está começando a ficar cara, talvez seja este o momento de se pensar em uma refatoração deste tipo. Irei tentar colocar algo assim em prática e vou postando os resultados aqui. Novamente, um feliz 2010 para todos!

, , ,

1 comentário