Caçando um bug de verdade: o método do detetive

O roteiro do detetive

Programa errado dá uma vontade quase física de sair mexendo em tudo: troca um sinal aqui, inverte uma linha ali, roda de novo torcendo. Esse estilo tem nome (programação por coincidência) e um histórico terrível: às vezes o erro some sem você saber por quê, o que significa que ele voltará sem você saber por quê. O detetive faz o oposto. Primeiro REPRODUZ o crime: encontra uma entrada concreta que faz o erro aparecer sempre. Um bug que aparece toda vez que a entrada é 0 já está meio resolvido; um bug que “às vezes acontece” ainda nem virou caso.

Com o erro reproduzível, entra a HIPÓTESE: um palpite específico e testável sobre a causa. Especificidade é o que separa hipótese de desespero. “O programa está errado” não ajuda ninguém; “a média sai errada porque a divisão acontece antes da soma completar” aponta para uma linha e diz exatamente qual teste a confirma ou derruba. A VERIFICAÇÃO é o rastreio da aula anterior: execute o trecho suspeito no papel e compare cada valor com o esperado. Se a hipótese sobreviver, você achou a causa. Se cair, comemore do mesmo jeito: um suspeito a menos, cerco mais estreito.

1. Reproduza: ache a entrada exata que faz o erro aparecer toda vez.
2. Hipotetize: escreva um palpite que aponte para uma linha ou trecho específico.
3. Verifique: teste de mesa no trecho suspeito, comparando cada valor com o esperado.
4. Corrija UM ponto: a menor mudança que ataca a causa encontrada.
5. Reteste: a entrada do erro E as entradas que já funcionavam antes.

O caso da média teimosa

Hora de resolver um caso de verdade. A escola encomendou um algoritmo simples: ler duas notas, calcular a média e dizer se o aluno foi aprovado (média 6 ou mais). O programa abaixo foi entregue e a diretora reclamou: um aluno com notas 4 e 6 apareceu APROVADO, com uma média estranha de 7. Reproduza no papel com essas notas, formule sua hipótese e cace a linha culpada. Dica de detetive: a média correta de 4 e 6 é 5, e o programa mostrou 7. Que conta produziria 7 com esses números? Essa pergunta É a hipótese.

Repare como o caso fechou: o valor errado (7) não foi tratado como azar, e sim como PISTA. Perguntar “que conta produz 7 com 4 e 6?” levou direto à divisão executada antes da soma, uma hipótese que o teste de mesa confirmou na terceira linha. É assim que detetives experientes trabalham: o sintoma nunca é aleatório, porque a máquina é literal. Todo valor errado foi calculado por alguma conta exata; encontre a conta e você encontrou o bug.

Corrija um ponto, reteste tudo

Causa confirmada, a correção deve ser a MENOR mudança que a ataca: no caso da média, um par de parênteses, e mais nada. Resistir à tentação de “aproveitar e melhorar outras coisas” é disciplina de profissional, porque cada mudança extra embaralha o experimento. E depois de corrigir vem o passo que separa o detetive do estagiário afoito: retestar TUDO. A entrada que revelava o bug (4 e 6, que agora deve dar 5 e reprovar) e as entradas que já funcionavam (8 e 8, que deve continuar dando 8 e aprovando). Correção que conserta um caso e quebra outro não é correção, é rodízio de bugs.

Um último hábito de quem depura bem: registre o caso. Uma linha de comentário no código (“parênteses obrigatórios: a divisão rodava antes da soma”) ou uma nota no caderno já bastam. Bugs são repetitivos por natureza: o mesmo padrão que pegou você hoje vai rondar seus próximos algoritmos, e o registro transforma cada caso resolvido em vacina. As equipes profissionais fazem isso em escala industrial: todo bug de produção vira um teste automático que impede o retorno dele para sempre. Você acabou de aprender a versão de bolso dessa cultura.