Introdução ao debugging de software

Por Luís Soares para o PPLWARE.COM

O debugging de um programa baseia-se em alguns princípios e técnicas transversais à maioria das linguagens e ambientes de programação. Tentarei, neste artigo, sintetizar o que entendo por debugging, introduzindo o tema, colocando algumas luzes nos conceitos fundamentais e mostrando que há um mundo para além de alerts e prints.

Debugging (ou depuração) é o processo pelo qual se identificam e corrigem bugs de software (ou hardware). Dominar o debugging é vital para um programador: os bugs vão inevitavelmente aparecer quando a complexidade (número de programadores, de requisitos, de linhas de código, de dependências, etc.) aumentar. No início, fazer debug costuma ser algo chato e/ou custoso (pelo menos para mim, era); mas, com a prática, torna-se mais interessante, pois:

• faz-nos compreender melhor o workflow do programa, o que se passa “por baixo”, assim como tecnologias envolvidas;
• obriga a criar bom código que evita bugs semelhantes no futuro;
• alguns bugs estimulam a nossa capacidade de resolução de problemas e motivam-nos quando resolvidos.

Evitando o debug

A melhor forma de fazer debug é evitar ter de o fazer. Devemos adotar técnicas e boas práticas que reduzam a probabilidade de ter bugs e outras que facilitem a sua correção caso ocorram. Eis algumas (cuja explicação sai fora do âmbito atual):

• Code reviewing e Pair programming;
• Decoupling, encapsulamento e modularidade;
• Uso correto de design patterns;
• TDD;
• Redução de dependências (ex. de tecnologias, de pessoas, do S.O.);
• Uso de convention over configuration;
• Princípios SOLID;
• Não faça copy/paste de código (nunca vale a pena);
• Mantenha o código limpo e tenha pouco código;
• Faça bons comentários;
• entre muitas outras boas práticas...

O processo de debug

O debugging, apesar de muito ligado à programação, é uma disciplina com o seu próprio processo. Mesmo não se pensando nisso, está-se implicitamente a segui-lo:

1. Reprodução: saber os passos a seguir, as condições iniciais, assunções, etc;
2. Diagnóstico: gravidade, prioridade, impactos, riscos, a zona em causa. Para este último:
3. Correção;
4. Reflexão: aplicação de medidas que garantam que o problema não se repete noutro formato: testes, documentação, validações de input e corner cases, criação de código mais resiliente, refactoring, etc.

Logo na reprodução do problema é frequente que o programador perceba o que está mal, passando logo para a correção. Se isso não suceder, passa-se então ao diagnóstico (o debugging propriamente dito), altura em que são aplicadas as seguintes técnicas (entre muitas outras):

• Fazer reverse engineering: análise de outputs e stack traces, de dump files, de pacotes de rede, de padrões de comportamento, entre outros;
• Tentativa/erro: quando não se tem a certeza dos contornos do problema e se colocam diversas hipóteses, seguindo-se a sua eliminação progressiva;
• Isolar o problema: por exemplo, comentando código não relevante no problema ou criando um sample project com o problema na sua versão mais simples;
• Reverter o código gradualmente, até se perceber o que causou o problema;
• Tracing (prints): a técnica mais comum: imprimir que se passou em algum lado e/ou variáveis disponíveis momentos;
• Uso de debugger: ferramenta por excelência para debugging (inclui controlo de fluxo, avaliador de expressões, consola, profiler, entre outros utilitários).

Vejamos o tracing e o debugging com ferramenta em mais detalhe.

Imprimindo (tracing)

Quem nunca fez debug com prints? Tracing é o método mais usado para debug. Fazer tracing é usar a consola (há quem use a própria GUI, embora isso não seja muito elegante...) para imprimir (i.e. exibir) o estado do programa sem bloquear o seu fluxo. Por outras palavras, permite saber o valor de variáveis (ou simplesmente dizer que se passou lá) quando se passa nos sítios com prints. Pode ser usado para debugging ou apenas registo (logging). Eis alguns exemplos de prints em diferentes linguagens:

* Em JavaScript, não use o alert(…), pois:

• este quebra o fluxo aplicacional e bloqueia a interface;
• não imprime objetos (apenas exibe [object Object]);
• impede o correto funcionamento de alguns objetos do DOM (ex. IndexedDB).

Consoante o ambiente (linguagem, plataforma, IDE e bibliotecas) em uso, cada linha de tracing pode conter várias informações, entre as quais:

• Mensagem
• Data e hora
• Linha de código (para stack straces)
• Gravidade: varia com a linguagem e biblioteca. Ao fazer tracing, deve fazer uso do nível de gravidade correto. Os mais comuns são:
  • Info: para registos gerais;
  • Warning: para avisos e coisas que não deviam acontecer;
  • Error: para erros de prováveis bugs (ex. SIGSEGV) e situações sem recuperação.
• Processo
• Aplicação

Características

• Simplicidade de uso; sempre presente e com poucos requisitos;
• Permite debug em tempo real pois não bloqueia o fluxo do programa; isto é especialmente patente quando não é possível fazer debug remoto e os prints no servidor são a única coisa que nos resta;
• Útil para análise de operações massivas, repetitivas, constantes, etc.;
• Útil para situações que podem ser inesperadas ou por perceber;
• Pode ser usado para manter registos (logging) para analisar mais tarde, lançar alarmística ou simplesmente guardá-los em arquivo;
• Muitas vezes, há limitações no que toca a imprimir objectos (tipos compostos);
• Só se pode ver o que se imprimiu… não há como voltar atrás;
• Imprimir é feito com instruções e portanto atrasa o programa;
• Se nos esquecermos de remover os prints, o código fica “sujo” (assim como o output/consola).

Deverá analisar as características da situação e perceber quando aplicar esta técnica. Muitas vezes, tem mais a ganhar recorrendo a debuggers...

Recorrendo a debuggers

Imagine que houve um acidente em cadeia na autoestrada… Agora, tinha de identificar a causa do acidente. Poderia repetir tudo, tinha o poder de parar todos os veículos em simultâneo, podia tirar fotografias, analisar cada veículo, dar ordem para se prosseguir, etc. Esta metáfora ilustra o papel de um debugger de software: uma ferramenta de apoio ao debug sistematizado. Pode ser oferecido:

• de forma isolada (ex. DDD, Ideone);
• integrado no IDE (ex. Xcode, NetBeans, Eclipse);
• ou integrado noutra ferramenta (ex. Chrome Developer Tools: pressione F12 no seu browser).

Falar em detalhe num debugger exigiria um conjunto de artigos e tutoriais. Tentarei apenas resumir os conceitos principais e transversais a qualquer debugger e linguagem, os quais deve tentar dominar.

É importante que perceba que um programa a correr representa (pelo menos) um fluxo de execução (na prática, uma thread). O estado de um programa é o conjunto de elementos que o descrevem num determinado momento (o conjunto de todas as variáveis).

Características

• Total controlo sobre o fluxo (pausa, passo-a-passo, entrar em função,...);
• Fácil análise do estado corrente a qualquer momento (call stack, variáveis, expressões, watches, inspeção de objetos, ...);
• Permite o debug a bibliotecas de terceiros (se forem open source);
• Mais difícil de usar em multithreading;
• Necessário compilar e correr código em modo de debug (com IDE isto é implícito);
• É necessário ter e conhecer ferramenta de debugging;
• Não muito útil para análises de padrões ou que ainda não percebemos bem quando podem suceder;
• Não funciona para problemas causados por race conditions.

Tutoriais de debuggers

• Visual Studio
• DDD
• Xcode
• NetBeans
• Eclipse
• Android Studio
• IntelliJ IDEA
• Chrome Developer Tools
• Firefox Developer Tool

Em conclusão

Embora intimamente ligado à programação, o debugging tem o seu próprio processo: reprodução, diagnóstico, correção e reflexão. O diagnóstico é geralmente efetuado recorrendo a tracing - imprimindo - ou utilizando uma ferramenta: o debugger. Estas não são técnicas concorrentes. De facto, são muitas vezes usadas de forma complementar. Um debugger permite analisar à lupa um problema; o tracing permite análises gerais. Ambas passam por:

1. Colocar de breakpoints e/ou prints nas zonas em causa;
2. Lançar do programa e reproduzir o problema;
3. Analisar do estado do programa quando ele passa pelas zonas em causa.

Os conceitos a reter e dominar num debugger são: breakpoints, steps, inspeção de objetos (variables e watches) e console

Quando o debugger é baseado na consola (ex. no GDB um step é um comando escrito), há desculpa para se recorrer ao tracing. Com as ferramentas gráficas disponíveis actualmente (varia com a linguagem), o tracing deve ficar relegado às suas funções. Este tem as suas limitações pelo que é fundamental que o programador domine o debugger. O problema é que se vêem programadores experientes a ignorar o seu poder, algo difícil de explicar (após o conhecerem, a sua produtividade aumenta e já não conseguem viver sem ele).

Possíveis tópicos a desenvolver em futuros artigos são os breakpoints condicionais e com hit count, o debugging remoto (ex. de um browser num telemóvel ou de uma aplicação web num servidor) e o uso de profiling.