Debugging: o que é e como começar

Debugging: o que é e como começar

Você escreve algumas linhas de código, executa o programa e, em vez do resultado esperado, aparece uma mensagem em vermelho. Ou pior: não aparece nenhuma mensagem, mas o resultado está errado. Para quem está começando a programar, esse momento costuma ser frustrante, mas também é uma das experiências mais formativas da profissão. Encontrar a origem de uma falha, entendê-la e corrigi-la tem um nome: debugging. Longe de ser um castigo ou um sinal de incapacidade, é uma parte central do trabalho de qualquer pessoa que escreve software.

Este artigo explica o que é debugging, por que os erros aparecem mesmo em código bem escrito, quais são os tipos de falhas mais comuns, quais técnicas básicas quem está começando pode aplicar, quais ferramentas facilitam a busca, com que mentalidade convém enfrentar o problema e quais hábitos ajudam a prevenir erros desde o início.

O que é debugging

Debugging é o processo de identificar, localizar e corrigir os erros de um programa. O termo tem uma história curiosa: em 1947, a programadora Grace Hopper e sua equipe encontraram uma mariposa dentro de um relé do computador Mark II e a colaram no livro de registro com uma anotação dizendo que tinham encontrado o primeiro caso real de um bug. Desde então, bug passou a ser qualquer defeito em um sistema, e a ação de caçá-los ficou conhecida como debugging. A história é simpática, mas vale esclarecer que a maioria dos bugs atuais não são insetos: são erros humanos que se infiltram nas instruções que damos à máquina.

Depurar não é apenas consertar o que se vê. É um processo de investigação que combina leitura cuidadosa, observação e raciocínio. Quando um programa falha, o código está fazendo exatamente o que pedimos; o problema é que o que pedimos não coincide com o que realmente precisamos. O debugging consiste em descobrir em que ponto a intenção e a instrução se separaram, corrigir essa diferença e verificar se a mudança resolve a falha sem quebrar outra coisa. Por isso ele é comparado ao trabalho de um detetive: parte-se de uma pista, o sintoma, e avança-se em direção à causa, descartando suspeitos um a um.

Por que os bugs existem

Os bugs existem porque o software é escrito por pessoas, e pessoas cometem erros. Um programa grande pode ter milhares ou milhões de linhas de código, e cada linha é uma decisão: como uma variável é nomeada, qual condição é avaliada, qual valor é armazenado. Em qualquer ponto dessa corrente um erro pode se infiltrar, quase sempre por razões muito humanas.

Entre as causas mais frequentes estão os erros de digitação, como escrever o nome de uma variável de forma diferente em dois lugares; os descuidos de lógica, como usar maior que quando deveria ser maior ou igual; as suposições erradas sobre os dados, como acreditar que um campo sempre chega com valor; e os mal-entendidos sobre o que o programa deve fazer, quando quem o escreveu interpretou o requisito de outra forma. Também surgem bugs quando uma parte do sistema é modificada sem prever como a mudança afeta as demais, ou quando o programa funciona em uma máquina e falha em outra porque o ambiente é diferente.

Vale dizer com clareza: ter bugs não significa ser um mau programador. Até desenvolvedores com décadas de experiência escrevem código com falhas; a diferença é que aprenderam a encontrá-las rápido. Os erros são parte natural do processo de criar software, e a habilidade que separa quem está começando de quem já tem experiência não é nunca errar, mas saber o que fazer quando algo falha.

Os três tipos de erros mais comuns

Para depurar com método, convém saber com que tipo de erro se está lidando. Em termos gerais, os erros se dividem em três grupos: de sintaxe, de execução e de lógica. A tabela a seguir resume as diferenças:

Os erros de sintaxe e de execução são os mais amigáveis, porque a própria ferramenta avisa que algo está errado e costuma indicar em qual linha. Os de lógica são os mais difíceis: a máquina não reclama, tudo funciona, e mesmo assim a resposta está incorreta. Nesses casos, o inimigo não está na forma do código, mas no raciocínio que o produziu, e encontrá-lo exige as técnicas descritas a seguir.

Técnicas básicas para começar a depurar

Não é preciso ser especialista para encarar um bug com método. Essas técnicas simples resolvem grande parte dos problemas, principalmente em código próprio e recente:

• Ler a mensagem de erro completa: parece óbvio, mas é a etapa mais ignorada. A mensagem diz o que falhou e quase sempre em qual linha. Vale a pena lê-la inteira antes de tocar em qualquer coisa, mesmo que esteja em outro idioma e seja preciso traduzi-la.
• Verificar a linha indicada: o local apontado costuma conter o problema, embora às vezes seja apenas o ponto onde o erro ficou visível e a causa real esteja algumas linhas antes.
• Imprimir valores para ver o que acontece: uma das técnicas mais antigas e eficazes consiste em mostrar no console o conteúdo das variáveis principais em diferentes momentos do programa. Com ferramentas como console.log ou print, é possível confirmar se um dado chega vazio, se uma condição é satisfeita ou se um cálculo produz o número esperado.
• Dividir o problema: quando uma falha parece gigante, o programa é separado em pedaços menores e cada um é testado isoladamente. Assim se descarta rápido qual seção funciona e a busca se concentra na que falha.
• Explicar o código em voz alta: narrar linha por linha o que o programa deveria fazer obriga a lê-lo com atenção, e muitas vezes a contradição aparece sozinha, sem mudar uma única letra.

A última técnica tem uma versão famosa e um tanto divertida: o método do patinho de borracha. Consiste em manter um patinho de borracha sobre a mesa e explicar o problema a ele com calma, passo a passo. O patinho não sabe nada de programação, mas enquanto se explica o que cada linha deveria fazer, quem fala acaba percebendo o próprio erro no meio da explicação. Parece absurdo, e é exatamente por isso que funciona: obriga a organizar as ideias com uma clareza que não se tem quando se olha para a tela com angústia.

Ferramentas que facilitam a busca

Além das técnicas manuais, existem ferramentas feitas para tornar o debugging mais rápido e menos baseado em adivinhação:

• O depurador do editor: os editores e ambientes de desenvolvimento modernos incluem um depurador que permite executar o programa passo a passo e observar o valor das variáveis a cada momento.
• Os pontos de interrupção (breakpoints): com eles, o depurador recebe a instrução de parar o programa em uma linha específica. Nesse momento é possível inspecionar o que cada variável contém e decidir se o comportamento é o esperado.
• As impressões no console: quando o depurador é exagerado para um problema pequeno, imprimir valores com console.log ou print continua sendo a opção mais rápida e direta, e funciona em qualquer linguagem.
• As ferramentas do navegador: quem desenvolve páginas web tem à disposição painéis que mostram os erros da página, as requisições de rede e valores em tempo real.

A regra prática é começar pelo simples: ler a mensagem, olhar a linha e imprimir alguns valores. O depurador com pontos de interrupção se torna indispensável quando o problema é complexo ou o código não é seu.

A mentalidade adequada

Depurar é, acima de tudo, um exercício de paciência. Quando um erro aparece, a primeira coisa a fazer é conter o impulso de mudar as coisas ao acaso até que algo funcione. Essa estratégia raramente corrige a causa e quase sempre adiciona bugs novos. Em vez disso, o processo recomendado é: ler com calma, isolar o problema, formular uma hipótese sobre a causa, fazer uma única mudança e testar de novo. Se a mudança não resolveu nada, descarta-se a hipótese e tenta-se outra.

Também ajuda isolar o problema do resto do sistema. Se a falha só aparece quando dois módulos são combinados, teste cada módulo separadamente para descobrir qual é o responsável. E quando o cansaço ou a raiva vencem a partida, a melhor decisão é fazer uma pausa: voltar com a cabeça fresca costuma revelar em minutos o que uma hora de insistência não mostrou.

Como prevenir erros desde o início

A melhor forma de depurar é precisar pouco dela. Embora os bugs nunca desapareçam por completo, vários hábitos simples reduzem a quantidade e facilitam encontrá-los quando aparecem:

• Testar em pedaços pequenos: escrever um módulo inteiro e testá-lo só no final garante que, se algo falhar, o problema pode estar em qualquer uma das cem linhas novas. Testar cada função assim que é escrita restringe a busca imediatamente.
• Escrever código claro: nomes descritivos de variáveis e funções, funções curtas e ordem lógica fazem o código ser lido como uma explicação, e o que é fácil de entender é mais fácil de corrigir.
• Guardar versões do que funciona: manter cópias do código que já funcionava permite comparar e voltar atrás quando uma mudança quebra algo.
• Verificar os dados: muitos bugs não estão no código, mas nos dados que ele recebe: campos vazios, formatos diferentes ou valores fora do intervalo. Revisar o que a informação de entrada realmente contém evita surpresas.

O debugging se aprende depurando. A cada erro encontrado e entendido, as mensagens do console deixam de ser ameaças e se tornam pistas, e a suspeita de que o programa está louco dá lugar à certeza de que, em algum lugar, há uma instrução que não diz o que deveria dizer. Essa busca, que no início parece um obstáculo, é na verdade uma das habilidades mais valiosas que qualquer pessoa que escreve software pode desenvolver.