Por que você relê o mesmo código três vezes e não enxerga o bug: o custo da familiaridade forçada

Você abre um diff pequeno, percorre as mesmas linhas várias vezes e ainda não consegue explicar exatamente o que mudou. A alteração parece correta porque corresponde ao que você pretendia escrever. Mas reconhecer a própria intenção não é o mesmo que verificar o código presente na tela.

Quando isso acontecer, não faça uma quarta leitura igual. Primeiro, descubra se o problema é cansaço visual ou familiaridade com a alteração. Depois, revise o diff sem reconstruir de imediato a história que já está na sua cabeça.

Familiaridade pode ajudar e também esconder

Conhecer um arquivo não é um problema por si só. Uma pesquisa de Alberto Bacchelli e Christian Bird sobre práticas e desafios da revisão moderna de código mostra que entender a mudança ocupa uma parte importante da revisão e que arquivos desconhecidos exigem mais contexto. Para outro revisor, a familiaridade pode facilitar a navegação pelo sistema e a avaliação da alteração.

Aqui, porém, o caso é mais específico: a autorrevisão feita logo após escrever o código. Você conhece tão bem o objetivo que pode completar mentalmente uma condição ausente, ler o nome que pretendia usar ou aceitar um fluxo por se lembrar de uma explicação que não está no diff.

Há uma analogia útil com a aprendizagem. A revisão de Dunlosky e coautores sobre técnicas de aprendizagem classifica a releitura como uma técnica de baixa utilidade e descreve retornos menores em releituras repetidas e concentradas. O estudo não avaliou código, mas traz um alerta prático: reconhecer um texto já visto é uma verificação fraca quando você precisa explicá-lo sem pistas.

Faça uma pergunta simples sem abrir o arquivo inteiro:

> Qual comportamento este diff deveria alterar e onde essa alteração pode falhar?

Se uma mudança pequena e localizada consumir mais de dez minutos e você ainda não conseguir responder em uma sentença, interrompa a releitura. Feche o contexto antigo e escreva a resposta. O ciclo improdutivo fica claro quando nem o comportamento novo nem o trecho de maior risco podem ser indicados.

Faça o teste de 60 segundos antes de insistir

Nem toda dificuldade vem da familiaridade. Ardência nos olhos, dor de cabeça ou caracteres difíceis de distinguir indicam que continuar diante da tela pode não ser uma boa escolha. Este teste não faz diagnóstico médico; ele apenas ajuda a decidir se a revisão deve continuar naquele momento.

A DevDojo sugere os cronômetros de 60 e 90 segundos usados neste artigo como limites práticos; são heurísticas, não resultados de laboratório.

Para o teste de 60 segundos:

1. Feche o diff.
2. Leia um parágrafo curto e não relacionado ao seu código.
3. Feche também esse texto e resuma-o em voz alta ou por escrito.
4. Se não conseguir, pare a revisão e descanse os olhos. Se conseguir, reabra somente o diff e tente nomear o comportamento alterado.

A dificuldade com o texto não relacionado, sobretudo quando há desconforto visual, pede uma pausa. Se você consegue resumi-lo, mas não consegue explicar o próprio diff, mude a forma de revisar em vez de insistir na mesma leitura.

Leia o diff em silêncio antes de abrir o arquivo antigo

Abrir o arquivo completo logo no começo fornece contexto, mas também recupera a narrativa que você já conhece. Na autorrevisão imediata, fica mais fácil justificar a alteração pela intenção original do que examinar o que foi adicionado e removido.

Leia apenas o diff em silêncio por 90 segundos antes de abrir o contexto antigo. O cronômetro serve para impedir a rolagem indefinida e exigir uma conclusão inicial.

No terminal, comece assim:

git diff --stat
git diff

Durante os 90 segundos, não abra os arquivos. Ao final, complete:

Isto deveria fazer X; o risco está em Y.

Por exemplo:

Isto deveria aumentar o timeout padrão do cliente; o risco está nos fluxos que esperam uma falha rápida.

Só então abra as linhas ao redor para conferir contratos, condições e efeitos laterais. Se o contexto mostrar algo diferente do que você escreveu, essa divergência já revelou uma falha de entendimento, mesmo que não seja um bug.

Transforme erros anteriores em pistas curtas

Uma lista genérica de boas práticas costuma levar a revisão para itens fáceis, como formatação e nomes. Em vez disso, crie uma lista de três a cinco falhas que você realmente cometeu ou quase deixou passar.

Estes exemplos mostram apenas o formato:

• condição invertida depois de renomear uma variável;
• exceção registrada e ignorada;
• data manipulada sem fuso horário;
• diferença entre valor nulo e coleção vazia;
• limite que exclui o primeiro ou o último item.

Substitua os exemplos pelo seu histórico e transforme cada item em uma pergunta curta: “inverti a condição?” ou “esta data tem um fuso definido?”. Durante uma semana, leia a lista antes de cada autorrevisão e procure somente esses padrões no diff.

No fim da semana, mantenha os itens que expuseram uma omissão ou levaram a uma checagem relevante. Remova os que nunca se aplicaram. Assim, a lista continua curta e ligada aos erros que de fato enganam você.

Evite trocar uma releitura por outra

A rotina perde utilidade quando muda apenas a aparência do hábito. Preste atenção a estes desvios:

• Rolar o diff durante 90 segundos sem chegar a uma hipótese. Quando o tempo acabar, complete a sentença, mesmo que a resposta seja incompleta.
• Abrir o arquivo antigo para “só conferir uma coisa”. Anote a dúvida e termine primeiro a leitura isolada.
• Encher a lista com regras de estilo. Prefira falhas de comportamento que já ocorreram no seu código.
• Tratar a técnica como garantia contra bugs. Ela organiza a autorrevisão, mas não substitui testes nem a revisão de outra pessoa.

Se você ainda não conseguir declarar o comportamento alterado, não reinicie o processo. Espere até o dia seguinte ou peça a outra pessoa que leia a mudança com o objetivo e o motivo explícitos.

Faça um experimento de 15 minutos por cinco dias

Reserve 15 minutos por dia durante cinco dias. Escolha uma alteração pequena ou um trecho modificado recentemente e siga esta ordem:

1. use o teste de 60 segundos se houver dúvida sobre cansaço;
2. leia somente o diff por 90 segundos;
3. escreva o comportamento esperado e o principal risco;
4. consulte sua lista pessoal;
5. abra o contexto ao redor.

Use um registro pequeno para anotar o que mudou:

Ao final dos cinco dias, compare o tempo necessário para explicar a alteração e confira se a leitura isolada ou a lista revelou algo ignorado na primeira passagem. Registre também os dias em que o método não ajudou.

Adote a rotina somente se ela reduzir o tempo até uma explicação clara ou revelar ao menos uma omissão antes ignorada. Se nenhum desses resultados aparecer, descarte a regra e não transforme o cronômetro em ritual.