Jesse Vincent (obra) / systematic-debugging
O que depurar sistematicamente dá que chutar não dá?
Uma causa que você consegue nomear, e um motivo para acreditar que o bug foi embora.
O que vale lembrar
- As fases existem para impedir o salto do sintoma para o patch.
- Uma causa nomeada é o que diz se a correção deveria funcionar, antes de você publicar.
- Em bugs intermitentes é onde mais rende, porque chutar ali é quase aleatório.
- Custa tempo em bugs simples. Guarde para os que já custaram um dia.
01O que muda na prática
Chutar e remendar funciona com frequência suficiente para ser perigoso. O bug some, todo mundo segue, e o defeito reaparece com outra cara quando o remendo deixa de cobrir.
Organizar o trabalho em fases deixa o raciocínio escrito enquanto ainda é barato contestar. Quando a causa declarada não explica todas as observações, esse descompasso fica visível em vez de enterrado num diff.
02Onde decepciona
Sem reprodução o processo trava na primeira fase, o que é honesto mas nem sempre é o que um time sob pressão quer ouvir.
Ela também se sobrepõe à mais leve diagnosing-bugs. Escolha a que combina com a cerimônia que seu time vai tolerar de fato.
Instalação e primeira execução
- Instale o superpowers a partir de obra/superpowers, sob licença MIT.
- Forneça uma reprodução confiável, ou aceite que a primeira fase será encontrar uma.
- Não aceite correção antes de a causa ser declarada e explicar o comportamento observado.
Perguntas que as pessoas realmente fazem
- Quando a sobrecarga compensa?
- Quando o bug é intermitente ou já sobreviveu a uma correção. Em bugs simples é mais lenta que corrigir.
- E se não houver reprodução?
- A primeira fase passa a ser encontrar uma. É a ordem correta, mesmo parecendo mais lenta que tentar uma mudança.
- Como se compara a diagnosing-bugs?
- Mesma intenção, mais estrutura. Escolha uma para o agente receber um conjunto único de instruções.
Fontes
Versões legíveis por máquina desta página