Mentalidad de debug
La forma científica de encontrar y arreglar bugs
⏱ Estim. ~8 min
01 · Leer
Tu código se va a romper. El código de todos los ingenieros se rompe. La diferencia entre un principiante y un profesional no es que el profesional escriba código sin bugs — es que el profesional sabe cómo encontrar y arreglar bugs de forma sistemática.
Debuggear no es prueba y error al azar. No es cambiar cosas esperando lo mejor. Es el método científico: observar, hipotetizar, probar, concluir.
Los ingenieros que parecen magos del debug no son más inteligentes — solo siguen un proceso en vez de entrar en pánico.
💡 Imagínalo asíDebuggear es como ser detective. Sucede un crimen (el bug). Recoges evidencia (mensajes de error, logs), formas una teoría (hipótesis), la pruebas (cambias una cosa) y, o resuelves el caso, o formas una nueva teoría. Nunca arrestas a alguien al azar esperando lo mejor.
02 · Paso a paso
El flujo de debug — sigue estos pasos cada vez que te encuentres un bug
1. REPRODUCE (reproducir)
¿Puedes hacer que el bug aparezca de forma consistente? Si es aleatorio, busca problemas de tiempo o de estado. Si no puedes reproducirlo, no puedes arreglarlo con confianza. Anota los pasos exactos que disparan el bug.
2. ISOLATE (aislar)
¿Dónde exactamente falla? Reduce a un archivo, una función, una línea específica. Usa console.log o mensajes de error para localizarlo. Mientras más pequeña sea el área a investigar, más rápido encuentras el problema.
3. HYPOTHESIZE (hipótesis)
¿Qué crees que lo causa? Forma una teoría antes de cambiar nada. "Creo que el bug pasa porque accedemos al índice 0 cuando el arreglo está vacío." Tener una teoría enfoca tu investigación.
4. TEST (probar)
Cambia una cosa para probar tu hipótesis. Nunca cambies varias a la vez — si cambias tres y el bug desaparece, no sabes cuál lo arregló. Esta disciplina te va a ahorrar horas más adelante.
5. FIX (arreglar)
Aplica el arreglo según lo que aprendiste. Un buen arreglo ataca la causa raíz, no solo el síntoma. Si los usuarios se caen cuando el arreglo está vacío, no escondas el error — maneja correctamente el caso del arreglo vacío.
6. VERIFY (verificar)
¿Sigue ocurriendo el bug original? ¿Rompiste algo más? Prueba el arreglo y luego prueba lo que está alrededor. Un arreglo que crea un bug nuevo no es realmente un arreglo.
03 · Leer
Vamos a aplicar el flujo en la práctica. Heredas una app con un bug — una API de contador de visitantes. Se cae cuando los usuarios pegan al endpoint /api/stats. Tu trabajo: sigue el flujo de debug para encontrar el bug.
04 · Práctica de terminal
Paso 1: REPRODUCE — lee el log de error para entender qué falla. Los mensajes de error son tus mejores amigos. Normalmente te dicen exactamente qué pasó y dónde.
(Esta sección es interactiva — activa JavaScript para usarla.)
05 · Práctica de terminal
Paso 2: ISOLATE — el error apunta a count undefined en la línea 7. Ese valor viene de getVisitorCount(). Lee el código y encuentra la función para ver qué falla.
(Esta sección es interactiva — activa JavaScript para usarla.)
06 · Leer
Aquí tienes las reglas de oro del debug que te van a ahorrar horas incontables. Pégalas en tu pantalla si hace falta.
Puntos clave
- No cambies varias cosas a la vez — no vas a saber qué lo arregló
- Lee los mensajes de error — normalmente te dicen qué falla y dónde
- Confía en el error, no en tu suposición de dónde está el bug
- Todos los ingenieros debuggean. Los ingenieros senior solo lo hacen de forma más sistemática.
07 · Completar
El primer paso del debug es _____ el bug de forma consistente.
08 · Quiz
¿Cuál es el primer paso del debug?
- Reproducir el bug de forma consistente
- Cambiar el código y esperar lo mejor
- Pedirle a Claude que lo arregle
- Borrar el archivo y empezar de nuevo
Otras lecciones de este capítulo
⚠ La experiencia interactiva completa necesita JavaScript. Actívalo y vuelve a cargar la página.
※ Este es un proyecto educativo independiente — no es un producto oficial de Anthropic. Claude™ es una marca registrada de Anthropic, PBC.