Depuração: Patologia forense versus medicina, uma analogia

December 3rd, 2007 § 5 comments

Há alguns meses atrás, um programador Ruby chamado Giles Bowkett publicou um texto um tanto ou quanto provocador com o título: Debugger Support Considered Harmful.

O grosso do argumento era que Ruby não precisa de um depurador porque possui testes automatizados. Desnecessário dizer, o texto provocou repostas inflamadas de vários outros programadores dizendo que Bowkett não sabia nem o que estava falando quanto mais o que um depurador era.

Controvérsias à parte, Giles Bowkett reconheceu depois que a terminologia era inadequada, embora não tenha reconhecido a principal falha no seu argumento. Por mais que se diga que testes são preventivos–e realmente o são–o pouco uso que se fazer de um depurador em Ruby se deve, com certeza, ao fato de que até pouco tempo atrás, o suporte ao mesmo era péssimo. Eu já conversei com dezenas de programadores Rails, por exemplo, e para tarefas em que o depurador é necessário, abunda a típica técnica de depuração que o pessoal do ASP costuma chamar de Response.Write debugging.

O fato é que um testes são, em última instância, verificadores de especificação. Não tem e nunca tiveram o propósito de ajudar um programador a identificar erros esdrúxulos escondidos no meio do código.

Um programador experiente introduz cerca de um bug a cada dez linhas de código, seja qual a linguagem ou ambiente que estiver usando de acordo com o que é possível observar na maioria dos projetos. Um teste pode e geralmente revela esses bugs e um programador experiente, na maioria das vezes, consegue identificar o problema com uma única olhada no código. Quando maior a experiência, maior a chance de que uma mera verificação do código em questão revele o problema.

Entretanto, há momentos em que o problema está escondido e é necessário passar o código linha por linha e acompanhar dezenas de variáveis em busca do defeito. Nesses casos, um teste é absolutamente inútil. Mesmo que o teste seja ajustado para lidar com pedaços ainda menores do código, certas condições não aparecerão a menos que o código seja testado item por item.

A falta de um depurador nesse momento vai simplesmente fazer com que o programador introduza artefatos como impressão de variáveis, comentários de partes do código e em geral use estratégias inferiores que poderiam ser resolvidas com um suporte um pouco melhor do ambiente de desenvolvimento. Infelizmente, linguagens de scripting sofrem um pouco mais com isso e, quanto mais seu uso se intensifica, mais o problema se torna claro.

Na seqüência de comentários resultantes do texto do Bowkett, uma das respostas mais interessantes foi de James Robertson, evangelista do Cincom Smalltalk.

Em sua resposta, Robertson compara o depurador existente na maioria das linguagens a um patologista forense. O depurador faz o papel de um CSI investigando a cena do crimeapós o fato tentando descobrir o que matou a vítima. Por outro lado, o depurador sofisticado de uma linguagem como Smalltalk é mais parecido com um médico, tratando um paciente anestesiado e resolvendo seu problema enquanto o mesmo ainda está vivo.

Qualquer um que tenha trabalhado com o depurador do Smalltalk sabe que a analogia é muito própria. Durante o desenvolvimento de uma aplicação Seaside, por exemplo, o processo mais comum de depuração é o seguinte:

  1. Um teste é desenvolvido para a funcionalidade
  2. O teste é rodado
  3. O teste falha e mostra onde o problema ocorreu
  4. O código em questão (que pode até não existir ainda) é mostrado no depurador
  5. O código é corrigido (ou criado, incluindo declaração de classes, variáveis, etc)
  6. A execução é reiniciada
  7. O teste passa

Se há um problema durante a execução da página, o processo é similar:

  1. A página mostra o erro e oferece um link para o depurador
  2. O link é clicado e o depurador se abre na imagem em execução
  3. O código é corrigido
  4. A página é continuada
  5. A página termina de executar, já com o novo código, como se nada houvesse acontecido

O depurador, então, é parte integral do processo de desenvolvimento e, na verdade, não deveria ser chamado de depurador. É mais um explorador do estado do código atual, visto dinamicamente.

Qualquer mudança feita durante a depuração se propaga pelo ambiente todo instantaneamente. Da mesma forma, se um erro acontece durante a depuração, um novo depurador é aberto com as mesmas propriedades. Corrigido o novo problema, a execução retorna ao depurador inicial e o processo continua daí. Não existem coisas como loops infinitos ou necessidade de reiniciar uma página ou código para testar a correção de um problema. Como Robertson coloca no final de seu texto, é uma questão de pedir ao sistema para se explicar sobre o que está acontecendo.

Nesse sentido, não há comparação entre os depuradores comuns, seja do Ruby ou do C# ou o que você quiser. A diferença é grande demais para ser considerada. E dizer que testes resolvem esse problema é a mesma coisa que dizer que você pode resolver problemas de código escrevendo documentação. A arrogância e a incompreensão simplesmente se tornam auto-evidentes.

§ 5 Responses to Depuração: Patologia forense versus medicina, uma analogia"

  • Diogenes says:

    A analogia realmente eh genial!
    To me sentindo tentado a trocar minha linguagem do ano de 2008!

    (Acho q voce vai ficar meio de lado Io[www.iolanguage.com]!!!)

  • C.E. Lopes says:

    De onde vem a métrica de um bug a cada 10 linhas de código?

    Curiosamente,

    C.E.

  • pedro says:

    puta merda, eu conheci o Giles esses dias

    faltou pouco pra falar que ele e’ um imbecil heheeh

  • RodrigoSol says:

    Pois eh, estou cada dia mais tentado a bricar com Smalltalk… Mais um incentivo.

    Você tinha comentado do esquema do debug do seaside onde você fazia a modificação do código no próprio browser, ou eu entendi errado? Não tem nenhum videozinho disso não?

    []’s

  • Ronaldo says:

    Diógenes, Smalltalk é uma linguagem que todo programador deveria aprender. Pode até não usar, mas a comparação vale a pena em todos os sentidos.

    C. E. Lopes, ironicamente, o Vinícius Teles citou na última palestra que eu assisti dele mas eu tinha lido originalmente no Dreaming in Code. Provavelmente tem raízes mais antigas (Fred Brooks ou coisa assim) e deve ser bem aproximada.

    Pedro, cruzes, o cara é tão mala assim pessoalmente. Ele escreve uma coisas legais mais a parte de Ruby guru não é com ele mesmo.

    Rodrigo, são duas coisas separadas. O Seaside exibe o ClassBrowser no navegador e você pode editar direto lá se quiser. Na depuração, ele oferece um link que pode invocar o debugger dentro da imagem.

Leave a Reply

Your email address will not be published. Required fields are marked *

What's this?

You are currently reading Depuração: Patologia forense versus medicina, uma analogia at Superfície Reflexiva.

meta