Inicio / Gestos cotidianos

Depurar y corregir un bug

Un comando de reproducción preciso y una traza de pila completa orientan el diagnóstico hacia la causa real de un bug, y la corrección no se declara cerrada hasta que se ha ejecutado un test de regresión que reproduce el caso defectuoso y se ha leído su salida.

Pegarle a Claude Code solo la última línea de un mensaje de error deja la causa real del bug fuera de vista. El flujo de trabajo documentado para corregir un bug de manera eficaz exige un gesto más completo: dar el comando que reproduce el problema y la traza de pila completa, no solo su última llamada mostrada en pantalla.

Reproducir antes de diagnosticar

Tres elementos marcan la diferencia entre una corrección que toca el síntoma y una corrección que toca la causa. El comando exacto que dispara el bug, la traza de pila entera desde el punto de entrada hasta el error, y una precisión sobre su carácter intermitente o constante. Un bug que solo aparece una vez de cada diez llamadas no tiene la misma causa que un bug que falla en cada llamada, y esta distinción orienta todo el diagnóstico que sigue.

El siguiente ejemplo fabrica sus propios datos para seguir siendo válido en cualquier lectura, sin tocar ningún archivo real de un proyecto. Una función que reparte un total entre un número de partes falla cuando ese número vale cero.

function partager(total, nombreDeParts) {
  return total / nombreDeParts; // ninguna guarda sobre nombreDeParts
}

console.log(partager(90, 3));  // 30, caso normal
console.log(partager(90, 0));  // Infinity, el bug real se esconde aqui

La traza de pila señalaría aquí la llamada exacta a partager(90, 0), el comando de reproducción sería esa llamada aislada, y la naturaleza del bug sería constante: cero partes produce siempre el mismo resultado inválido, nunca un error intermitente.

El correctivo no se cierra con el verde inmediato

Una vez identificada la causa, la corrección se limita al código responsable, sin retocar lo que ya funcionaba. El gesto final consiste en exigir un test de regresión que reproduzca exactamente el caso defectuoso observado, y luego leer su salida antes de considerar el bug cerrado.

function partager(total, nombreDeParts) {
  if (nombreDeParts === 0) throw new Error("nombre de parts invalide");
  return total / nombreDeParts;
}

try {
  partager(90, 0);
} catch (erreur) {
  console.log("test de régression : ", erreur.message);
}

Esta exigencia enlaza directamente con la escritura del test antes de la implementación: en ambos casos, la confianza viene de una salida ejecutada y leída, no de una relectura del código corregido.