Chutar não é fazer debug

Quatro mudanças, zero entendimento

Imagine um bug: article.published? retorna false quando deveria retornar true. Um primeiro movimento comum é mudar algo e rodar de novo. Adicionar um .presence aqui, trocar nil por false ali, reordenar duas linhas, jogar um puts e ficar olhando pro resultado. Quatro edições depois o bug continua lá. Ou pior: ele "some" por acidente, ninguém sabe por quê, e ele volta assim que o código mudar de novo.

Isso é editar código na esperança de acertar, e não fazer debug. Funciona por sorte com frequência suficiente para parecer produtivo, mas não escala além dos bugs mais simples, e não ensina nada sobre o sistema por baixo.

O método científico de verdade, aplicado a código

Debug como disciplina pega emprestado diretamente do método científico: quatro passos concretos, nessa ordem.

1. Observar o comportamento real: não o que o código deveria fazer, o que ele faz, confirmado diretamente, agora.
2. Formar uma hipótese específica: um único palpite falseável sobre a causa, preciso o suficiente para poder estar errado.
3. Projetar o menor teste possível: o mínimo de trabalho que provaria ou derrubaria essa única hipótese, nada além disso.
4. Mudar uma variável de cada vez: testar uma coisa antes de mexer na próxima, para que um resultado possa ser atribuído a algo específico.

Cada passo justifica o próximo. Pular direto para "mudar alguma coisa" sem observar e formular hipótese antes é o padrão das quatro edições aleatórias, só que com mais confiança embutida.

O exemplo central deste curso

Toda aula aqui trabalha em cima de um bug real em ScratchDebugArticle, um model descartável construído para este curso. Seu método published? foi modelado direto no Article#published? ilustrativo do curso "Visão geral do Rails MVC". Alguém define published_at num artigo, esperando que published? retorne true, e não retorna. A aula 2 começa aí, confirmando o que acontece antes de chutar o porquê.

Para onde este curso vai

A aula 2 observa o comportamento real e atual dessa chamada quebrada. A aula 3 transforma essa observação numa hipótese falseável. A aula 4 projeta o menor teste possível pra ela. A aula 5 cobre uma segunda e uma terceira hipótese, uma variável de cada vez. A aula 6 vai de uma hipótese confirmada até uma correção de verdade. A aula 7 reproduz a sessão inteira do começo ao fim.

Isso se apoia no curso "Console Rails (IRB)": toda hipótese aqui é testada no prompt do bin/rails console. É a mesma ferramenta que aquele curso usou para chamar métodos em objetos reais e ler o que eles retornam.