Como você efetivamente usa rastreamento e depuração

5

Eu sou um programador C # autodidata e até agora não tenho usado o Debug and Trace e sinto que deveria usá-los. Eu tenho me inclinado mais em TDD para entender e receber feedback do meu código.

O Guia do Desenvolvedor do .Net Framework se recusa a especificar diretrizes gerais para o posicionamento estratégico de instruções de rastreio "porque os aplicativos que usam o tracinig variam muito ..." ;

Quais são as suas experiências de usar o Debug / Trace? O uso excessivo deles cria problemas de manutenção de código? Quanta saída é demais? Quanto é muito pouco? Que tipo de coisas você tende a gravar?

    
por Grokodile 22.05.2011 / 04:05
fonte

1 resposta

3

Do ponto de vista de um desenvolvedor, ter uma grande quantidade de informações de rastreamento é uma dádiva absoluta quando você recebe um relatório de bug de um cliente, pois ele permite reproduzir e diagnosticar rapidamente a causa de um bug a partir de um arquivo de log: todos os bugs levantam exceções, e isso vale duplamente para os realmente desagradáveis.

Quando um relatório de bug chega, eu diria que quanto mais detalhado for o registro, melhor. Além disso, quando você está executando seu código, para poder observar o que ele está fazendo em tempo real na visualização de depuração é realmente muito útil, especialmente para o código multithread. Eu acho que isso precisa ser qualificado dizendo que você quer minimizar a repetição para melhorar a legibilidade; mas, em geral, quando um bug chega à sua mesa, você geralmente não pede menos informações.

Existem algumas boas razões para não usar o rastreamento:

  1. Isso pode levar a um horrível e feio código de código que pode impedir a refatoração. Colocar uma função de saída "enter function" em quase todos os métodos é um pesadelo de manutenção e parece errado. Em C # você pode usar Post Sharp, que resolve esse problema injetando IL em seu código para que você nunca veja essas chamadas, mas em geral eu acho que não há como contornar isso.
  2. Diminui o código para baixo. Isso pode não ser um problema muito grande: se o gargalo na execução estiver acessando o banco de dados, o registro em log detalhado não será um problema. No entanto, se forem os cálculos em si que são o gargalo, o registro em log detalhado provavelmente fará com que seu código seja muito lento para ser utilizável.
  3. Os dados podem conter informações confidenciais que você não pode registrar: há maneiras de contornar isso, como criptografar o arquivo de log em tempo real, mas isso resulta em uma sobrecarga de desempenho e apenas você sabe se isso é aceitável para seu aplicativo ou não.
  4. Grandes quantidades de dados de rastreamento podem se tornar difíceis de controlar. Por exemplo, a estrutura de testes de unidade da Microsoft para o Visual Studio exibirá todo o log de rastreamento / depuração após um teste de unidade falhar: se seu código for pequeno e atômico, tenho certeza de que funciona muito bem. Se você tiver código que não se presta a testes facilmente e você acaba criando alguns MBs de dados de rastreamento / depuração para executar um único teste, o IDE irá travar por um ou dois minutos enquanto tenta exibir esses dados.
por 22.05.2011 / 08:54
fonte