Debugging: Encontrándolo por tu cuenta

La mayoría de principiantes tratan un bug como una pared. Lo golpean, se detienen, y le piden a alguien más que lo escale por ellos. El hábito que realmente construye habilidad es diferente: aprendes a tratar un bug como una pregunta con una respuesta encontrable, y vas a encontrarla antes de ir a pedir ayuda.

Lee el mensaje de error como si fuera evidencia, no ruido

Los stack traces se saltan constantemente porque se ven aterradores. Pero por lo general te están diciendo exactamente dónde y por qué algo se rompió. Si obtienes TypeError: 'NoneType' object is not subscriptable en Python, eso no es galimatías aleatorio — significa que una variable que esperabas que contuviera una lista o un diccionario es en realidad None. El número de línea te dice dónde. Tu trabajo es rastrear hacia atrás desde esa línea y encontrar dónde el valor debería haber sido asignado pero no fue.

Haz esto antes de buscar cualquier cosa en línea: lee la última línea del traceback primero, luego trabaja hacia arriba. La última línea normalmente nombra la excepción real. Las líneas arriba muestran la cadena de llamadas que te llevó allí.

Reproducelo a propósito

Si un bug solo aparece a veces, aún no lo entiendes. Antes de tocar código, intenta hacerlo ocurrir de manera confiable. Cambia una entrada a la vez. ¿Falla con una lista vacía pero no con una llena? ¿Falla solo en la segunda llamada a una función, no en la primera? Un bug que puedes reproducir bajo demanda es un bug que está 80% resuelto, porque ahora puedes probar si una corrección realmente funcionó en lugar de adivinar.

Corta el problema por la mitad, luego por la mitad otra vez

La búsqueda binaria no es solo para arreglos ordenados — es la forma más rápida de encontrar código roto en una función larga o pipeline. Comenta o ignora la segunda mitad de tu lógica y verifica si la primera mitad aún produce el bug. Si es sí, el problema está en la primera mitad. Si es no, está en la segunda. Repite. Esto funciona para un script de 200 líneas igual que funciona para un pipeline de datos multietapa donde verificas outputs en cada etapa con print() o df.head().

Esto supera cambiar líneas aleatoriamente y ejecutar nuevamente, que es lo que la mayoría de la gente hace bajo presión y desperdicia mucho más tiempo del que ahorra.

Usa el debugger en lugar de print() cuando print() deja de funcionar

Los statements print() están bien para casos simples, pero una vez que persigues estado a través de múltiples llamadas de función, un debugger real ahorra tiempo real. En Python, pon import pdb; pdb.set_trace() justo antes de la línea sospechosa, ejecuta el script, y obtienes un prompt en vivo donde puedes inspeccionar variables, avanzar línea por línea con n, y entrar en llamadas de función con s. El debugger integrado de VS Code hace lo mismo con breakpoints que haces clic en lugar de escribir. De cualquier forma, el objetivo es el mismo: observa el estado real de tu programa en lugar de adivinar cuál es probablemente.

Aíslalo del resto de tu proyecto

Si un bug ocurre dentro de una base de código grande, no lo depures dentro de la base de código grande. Copia la función relevante a un archivo fresco con entrada fake y mínima que dispare el mismo fallo. Si el bug desaparece, algo sobre el contexto circundante — una variable global, un import, estado obsoleto — es la causa real, y acabas de aprender algo importante. Si el bug persiste en aislamiento, ahora tienes un caso pequeño, compartible, testeable, y estás mucho más cerca de la corrección real.

Verifica tus suposiciones contra la realidad, no contra la memoria

Una enorme parte del tiempo de depuración va a suposiciones sin cuestionar: