Jesse Vincent (obra) / systematic-debugging
¿Qué te da depurar de forma sistemática que no te da adivinar?
Una causa que puedes nombrar, y una razón para creer que el fallo se fue.
Lo que conviene recordar
- Las fases existen para impedir el salto del síntoma al parche.
- Una causa con nombre es lo que te dice si el arreglo debería funcionar, antes de desplegarlo.
- En fallos intermitentes es donde más rinde, porque adivinar allí es casi aleatorio.
- Cuesta tiempo en fallos simples. Resérvala para los que ya te costaron un día.
01Qué cambia en la práctica
Probar y parchear funciona lo bastante a menudo como para ser peligroso. El fallo desaparece, todos siguen, y el defecto reaparece con otra forma cuando el apaño deja de taparlo.
Ordenar el trabajo en fases deja el razonamiento escrito mientras aún es barato discutirlo. Cuando la causa declarada no explica todas las observaciones, ese desajuste se ve en lugar de quedar enterrado en un diff.
02Dónde decepciona
Sin reproducción el proceso se atasca en la primera fase, lo cual es honesto pero no siempre es lo que un equipo con prisa quiere oír.
Además se solapa con la más ligera diagnosing-bugs. Elige la que encaje con la ceremonia que tu equipo va a tolerar de verdad.
Instalación y primera ejecución
- Instala superpowers desde obra/superpowers, con licencia MIT.
- Aporta una reproducción fiable, o asume que la primera fase será encontrarla.
- No aceptes un arreglo hasta que la causa esté declarada y explique el comportamiento observado.
Preguntas que la gente hace de verdad
- ¿Cuándo compensa la sobrecarga?
- Cuando el fallo es intermitente o ya sobrevivió a un arreglo. En fallos simples es más lenta que arreglarlos.
- ¿Y si no hay reproducción?
- La primera fase pasa a ser encontrarla. Es el orden correcto aunque parezca más lento que probar un cambio.
- ¿Cómo se compara con diagnosing-bugs?
- Misma intención, más estructura. Elige una para que el agente reciba un único conjunto de instrucciones.
Fuentes
Versiones legibles por máquina de esta página