Técnicas de debug

O modelo mental antes de alcançar qualquer ferramenta:

1. Reproduzir: consegue fazer acontecer de novo? De forma confiável? Se não consegue reproduzir consistentemente, não consegue debugar.
2. Isolar: reduza onde acontece. Abordagem busca binária: comenta metade do código, ainda acontece? Continue cortando pela metade.
3. Entender: forme uma hipótese sobre o por quê. Não adivinhe aleatoriamente, faça uma previsão e teste.
4. Corrigir: só depois que entender a causa raiz. Corrigir sintomas é temporário.
5. Verificar: o fix realmente resolveu? Quebrou algo mais?

Note que mudar as coisas aleatoriamente sem entender é "programação voodoo", às vezes "funciona" mas o bug volta.

A humilde declaração de print é subestimada. Colocação estratégica bate debugger para maioria dos bugs. Técnicas:

• Imprima valores na entrada de cada função para rastrear fluxo de dados
• Imprima antes e depois da linha suspeita
• Imprima tipos, não só valores (typeof, type())
• Use labels descritivos: console.log("valor antes do filtro:", items) não só console.log(items)

Dica: muitos logs criam ruído. Remova debug prints antes de committar (ou use um logger com níveis).

Quando print não basta, use o debugger step-through. Intro prático:

• Browser DevTools: aba Sources, breakpoints, step over/into/out
• VS Code debugger: launch.json, breakpoints na IDE, funciona para Node.js, Python, etc
• Conceitos: breakpoint (pause aqui), step over (próxima linha), step into (entra na função), step out (sai da função), watch expressions (observa uma variável), call stack (como chegamos aqui)

Dica concreta: coloca breakpoint LOGO ANTES do bug, não antes de tudo. Depois dá step line a line e observa quando o valor fica errado.

Os antipadrões:

• Mudar muitas coisas ao mesmo tempo: você não sabe mais o que fixou (ou se fixou algo). Muda uma coisa, testa, depois muda a próxima.
• Não ler o erro completo: o stack trace te diz arquivo e linha. Maioria lê primeira linha e chuta. Lê tudo, especialmente a parte "caused by".
• Assumir que o bug está onde você está olhando: o erro se manifesta na linha 47 mas a causa é na linha 12 onde dados ruins foram criados.
• Debug por esperança: "deixa eu tentar essa coisa aleatória" sem hipótese. Consome horas.
• Não usar git bisect: se algo funcionou ontem e quebrou hoje, git bisect faz busca binária no seu histórico git para achar o commit que quebrou.

Referência rápida, não exaustiva:

• Erro de tipo, null, undefined: adicione validação de entrada na função, log do valor antes da linha que quebra
• Loop infinito ou lentidão: use profiler do browser ou time <comando> no terminal para medir, adicione contador temporário no loop
• Bug intermitente (race condition): adicione timestamps nos logs, procure por async/await faltando, eventos disparados fora de ordem
• "Funcionava ontem": git diff HEAD~1 mostra o que mudou, git bisect se histórico for longo
• Bug só em produção: ative logging mais verboso em produção temporariamente, reproduza localmente com dados de produção (anonimizados)

Debug é uma habilidade prática que melhora com prática. Próximo passo: leia o-que-sao-apis-e-como-usar para técnicas específicas de debugar chamadas de API.

Checklist antes de próxima vez que travar:

- [ ] Consigo reproduzir o bug de forma consistente antes de tentar corrigir?
- [ ] Leio o stack trace completo quando aparece um erro?
- [ ] Já usei o debugger do VS Code ou do browser pelo menos uma vez?
- [ ] Conheço o conceito de git bisect para encontrar commits que introduziram bugs?