Caros,

toda boa aplicação tem um Log. Infelizmente não estamos livres de bugs pós entrega ou erros do usuário e nesse ponto que o Log salva a vida do desenvolvedor.

O motivador desse artigo foi uma aplicação que envolvia todos os problemas possíveis e o log tinha que ser muito completo. Assim, vou abordar os tópicos para escrever um log informativo.

Por que escrever um log?

• Pegar um erro do programa: Bug pode ser do seu programa ou da interação com outro programa. Lembre-se, não é possível debugar um programa no ambiente do usuário.
• Registrar as cagadas ações do usuário: O usuário também pode interagir do jeito errado, fazendo uma sequência errada ou entrar do dados errados. O usuário também pode ser mal-intensionado e tentar hackear o sistema.

O que um log precisa?

• Quem disparou a ação: Ou seja, qual parte do software disparou a ação.
• Dados de entrada: Algo de fez o erro ser disparado, por exemplo, se foi um erro na atualização de cadastro de funcionários, é importante saber o quais dados foram inseridos ( como data de nascimento do tipo mm/dd/yyyy ao invés de dd/mm/yyyy )
• Resposta de outros sistemas: muitas vezes o problema é a comunicação com o outro sistema ou o bug está no outro sistema logo, tenha registrado essa resposta ( ex: banco de dados ou erro ao abrir algum arquivo )
• Data e hora: quando ocorreu o erro ou a ação do usuário.
• Usuário do sistema: para pegar o idiota usuário que provocou a ação.

Onde gravar o log?

O log pode ser gravado de 2 formas:

• Arquivo Texto: A forma mais comum. O programa vai acumulando texto e gravando no tal arquivo, entretando há um problema: em qual pasta guardar isso, pois pastas no computador do usuário têm restrição de gravação, assim se recomenda gravar no temporário do usuário ( %TEMP% no caso do Windows ou pastas com permissão de escrita no Linux ).
• Banco de Dados: Muitas vezes é cada registro de erro ou movimento do usuário pode ser guardado num banco de dados. A grande vantagem disso é poder fazer facilmente relatórios e consulta as imformações, porém, é mais complexo e existe o risco da indisponibilidade do servidor de BD.

Outros detalhes

Quando se pede para um usuário te passar o log do sistema, há o risco de alteração dele. Caso isso seja crítico a negócio, pode usar encriptação ou/e assinatura digital no documento para garantir a sua autenticidade.

Exemplo de Log

Vamos imaginar uma simples aplicação de cadastro de pessoas. Vamos simular um bug e uma entrada errada:

———————————————————————————————————————————-

Cadastro de Pessoas: usuario jose

Data: 09/12/2007 12:44

Cadastro do usuario #124 feito com sucesso.

———————————————————————————————————————————-

Cadastro de Pessoas: usuario joao

Data: 09/12/2007 16:12

Erro no cadastro: Problema #688 na comunicação com o banco de dados

Data Base not connected!

———————————————————————————————————————————-

Cadastro de Pessoas: usuario maria

Data: 12/12/2007 16:00

Erro no cadastro: Erro na data de nascimento. Data não está no formato dd/mm/aaaa

———————————————————————————————————————————-

Lembre-se: o log é um registro que pode te ajudar na procura de problemas e também como registro das ações do usuário que é um registro que pode ter implicações legais.

Espero que esse artigo tenha ajudado a vocês fazerem bons logs! Até!