Debug sistemático: como parei de adivinhar e comecei a investigar
Durante meses eu debugava no estilo tentativa e erro. Trocava uma linha, rodava, olhava. Não funcionava, trocava outra. Aprendi que isso não é debug — é loteria.
Passei duas horas trocando código aleatoriamente tentando resolver um bug.
Mudava uma linha, rodava. Não funcionava. Mudava outra. Não funcionava. Revertia a primeira. Tentava uma terceira. Era como resolver um labirinto com os olhos fechados dando passos em direções aleatórias.
O sênior do time chegou, olhou por cinco minutos, e perguntou: "o que você sabe sobre o bug?"
Respondi que não sabia nada além de que não estava funcionando.
"Então não comece a mudar código. Comece a entender o que está acontecendo."
Essa distinção — entender vs. corrigir — é o que separa debug sistemático de tentativa e erro.
O processo que aprendi a partir daí tem quatro movimentos: primeiro, reproduzir o bug de forma confiável. Se você não consegue reproduzir, não está debugando — está chutando. Bug intermitente que não sabe como reproduzir é um bug que não pode investigar.
Depois, identificar onde o comportamento diverge do esperado. Não onde você acha que está o problema — onde o código faz algo diferente do que você espera. Use print statements ou um debugger para observar o estado.
Depois, formular hipótese. "Acho que o problema está em X porque Y." Não é chute — é hipótese testável. Então testar com a menor mudança possível. Se estava errada, você aprendeu algo. Vai para a próxima.
A parte que me custou mais aprender: a hipótese pode estar errada e tudo bem.
Quando você formula hipótese errada, não é fracasso — é eliminação. Você sabe o que não é o problema, o que restringe o espaço onde o problema pode estar.
O debug que demora não é o que tem muitas hipóteses erradas. É o que não tem hipóteses nenhuma e fica mudando código no escuro.
Tem um caso clássico que me aconteceu: o bug só aparecia quando o payload tinha um campo específico com acento. Passei tempo olhando para a lógica de negócio quando o problema era encoding de string na fronteira de entrada.
Se eu tivesse isolado as variáveis mais cedo — testado com payloads diferentes para ver qual padrão reproduz o bug — teria chegado lá em 20 minutos em vez de 2 horas.
Bug que só aparece com dado específico = problema na fronteira de entrada ou no processamento desse dado. Quando você tem esse padrão, você tem a direção da investigação.
Essa semana: próximo bug que você encontrar, escreve em uma frase o que você sabe sobre ele antes de tocar no código.