Cómo depurar código de software en 7 pasos repetibles

Un carrito de compra puede compilar sin errores y aun así regalar 5 dólares de más. En este ejercicio controlado, el defecto se solicitó deliberadamente: se aplica un cupón una vez y luego un cambio de cantidad lo vuelve a descontar. La pregunta útil es cómo demuestras dónde ocurre exactamente ese descuento adicional.

La aritmética hace que la investigación sea concreta. Un carrito de 54 dólares pasa a** 49 dólares** con un cupón. Si añades otro artículo de** 24 dólares**, el total correcto con descuento debería ser** 73 dólares**. El cálculo defectuoso produce** 68 dólares**. Puedes usar esa discrepancia para rastrear el cambio de estado en lugar de adivinar qué línea parece sospechosa.

Al explicar cómo depurar código de software, empiezo con una regla: preserva el fallo antes de editar el programa. Define el resultado esperado, acota la búsqueda y prueba una causa. Un parche resulta convincente cuando explica la discrepancia y sobrevive a la misma secuencia que la reveló.

Entiende el bug antes de depurarlo

Separa el síntoma de la causa raíz

El síntoma es lo que puedes observar: un total incorrecto, un fallo, una página vacía o una solicitud que nunca termina. La causa raíz es la suposición violada que lo produce. En el ejemplo del carrito, el descuento crece cuando cambia la cantidad, aunque el importe fijo del cupón debería permanecer en 5 dólares.

Yo no empezaría cambiando el formateador de moneda; este solo muestra el resultado que recibe. Sigue el valor hacia atrás a través del componente de resumen, el cálculo del total, la acción de cantidad y el estado del cupón, hasta encontrar la primera divergencia respecto al cálculo esperado.

Este es un hábito útil al depurar código que no escribiste. Un stack trace o un nombre de componente que parece sospechoso te da un punto de partida, no un veredicto. El origen puede estar más atrás en el flujo de datos, o fuera del proceso que muestra el fallo.

Clasifica el fallo

Un error de sintaxis impide que el código se ejecute cuando su estructura infringe las reglas del lenguaje de programación.

Un error de sintaxis impide el análisis; una** excepción en tiempo de ejecución** interrumpe la ejecución; un** error lógico** produce un resultado incorrecto. Los defectos de integración aparecen en los límites entre sistemas. Los fallos de entorno dependen de la configuración, los permisos o las dependencias; los defectos de concurrencia dependen del timing y el estado compartido.

Nuestro defecto del cupón es principalmente un problema de estado y lógica. Las herramientas de build pueden aceptar todos los archivos mientras el cálculo de negocio sigue siendo incorrecto. Deberías elegir evidencia que coincida con la clase de fallo, en lugar de esperar que un comando exitoso establezca la corrección.

Preserva la evidencia y evalúa el impacto

Registra el resultado esperado, el resultado real, la entrada exacta, la secuencia de acciones y la versión defectuosa. Añade detalles del entorno, marcas de tiempo, identificadores de solicitud, logs y cambios recientes cuando sean relevantes. Quieres que otra persona pueda llegar al mismo fallo sin reconstruir tu sesión de memoria.

Distingo entre investigación y contención. Si un defecto en producción está cobrando un importe incorrecto, primero detén o restringe la ruta afectada mediante una mitigación autorizada. Un ejercicio de carrito descartable permite experimentar libremente; un incidente de pago real requiere cambios controlados y un responsable claro.

Cómo depurar código de software en 7 pasos repetibles

Los pasos forman una secuencia, pero puedes alternar entre inspección y prueba de hipótesis. Cada ciclo debería reducir la incertidumbre. Si te encuentras editando repetidamente archivos no relacionados, detente y pregúntate qué observación separaría con más fuerza las explicaciones restantes.

Una investigación repetible preserva la reproducción mientras reduce el número de causas plausibles.

Paso 1 — Define y reproduce el fallo

Sustituye "el cupón está roto" por una secuencia concreta: carga el carrito, aplica el cupón de 5 dólares, aumenta la cantidad del artículo de 24 dólares de uno a dos, y luego compara el total con 78 − 5 = 73 dólares. Incluye las cantidades iniciales para que el resultado esperado sea inequívoco.

Los importes 49 $ y 68 $ son visibles en capturas sucesivas de la vista previa defectuosa. El valor inicial de 54 $ se especifica en el plan y en el informe de build; una vista previa posterior ya reparada y reiniciada también muestra 54 $. Las capturas de pantalla preservan estos estados, mientras que una grabación o una prueba de interacción verificaría la secuencia completa de clics.

Para un fallo intermitente, registra la frecuencia y las condiciones en lugar de inventar una secuencia determinista. "Tres fallos en veinte intentos tras reconectar" es evidencia útil si esos intentos quedaron registrados. "A veces falla" te da poco con qué comparar.

Los valores esperados siguen los precios de la demo. El resultado defectuoso resta el mismo cupón de 5 $ por segunda vez.

Paso 2 — Redúcelo al caso de fallo más pequeño

Elimina todo lo que no afecte a la discrepancia. Nuestra aritmética solo necesita precios y cantidades de artículos, el estado del cupón y el cálculo del total. Las imágenes de producto, la búsqueda, el envío y la integración de pagos no explican un descuento fijo adicional en este ejercicio controlado.

Mantengo intacta la transición importante mientras reduzco el código circundante. Un ejemplo mínimo que elimine la acción de cantidad podría eliminar también el bug. Necesitas una reproducción más pequeña del mismo fallo, no un programa diferente que funcione por casualidad.

Documenta lo que eliminaste y confirma que el síntoma sigue ocurriendo. Esa confirmación te protege de sacar conclusiones sobre una prueba que ya no ejercita la ruta original. En un bug dependiente de datos, reduce el conjunto de entradas sin cambiar el valor que lo dispara.

Paso 3 — Inspecciona errores, logs, frames de pila y estado

Lee primero el fallo relevante inicial, antes de la cascada posterior. Inspecciona los valores reales en el límite: cantidades de artículos, subtotal, importe del cupón y total mostrado antes y después del cambio. La pregunta importante es si el descuento se aplica dos veces, no si la interfaz muestra una etiqueta concreta.

Las herramientas de depuración de VS Code exponen variables, expresiones de watch, frames de pila y controles de ejecución. Usa un breakpoint donde se asigna el total y luego inspecciona los llamadores y los valores actuales. Yo sigo el mismo valor a través de escrituras sucesivas en lugar de detenerme en el primero que parece plausible.

Una interfaz de depurador real capturada de la documentación de VS Code. El panel muestra varios tipos de evidencia a la vez.

Un defecto lógico puede no generar ninguna excepción. Puedes registrar temporalmente las entradas y el resultado calculado, o pausar justo antes de la asignación incorrecta. Mantén las observaciones lo bastante acotadas para interpretarlas; una consola llena de objetos completos a menudo entierra la transición que necesitas ver.

Paso 4 — Acota el espacio de búsqueda

Divide la ruta sospechosa en límites útiles. ¿Está mal el estado del artículo, está mal el subtotal, o el total mostrado se vuelve incorrecto después? Si el subtotal es 78 dólares pero se muestra** 68 dólares**, puedes dejar de investigar la multiplicación y examinar la aplicación del descuento.

Para una regresión, git bisect busca entre una revisión conocida como buena y otra conocida como mala. En una búsqueda binaria ideal, 1.024 candidatos se reducen a uno en 10 rondas de bisección. Las investigaciones reales también necesitan puntos finales fiables, builds reproducibles y una comprobación confiable de bueno-o-malo.

Bisect encuentra el cambio asociado a una regresión; no explica por sí mismo la causa subyacente.

El gráfico ilustra una búsqueda ideal. Builds rotos, revisiones omitidas o varios fallos no relacionados pueden complicar una ejecución real.

Yo ejecutaría un bisect en un worktree limpio o una rama descartable, preservando antes cualquier trabajo sin commitear. Marca una revisión como mala solo cuando la misma reproducción falle. Un problema de instalación de dependencias no relacionado no es evidencia de que el cálculo del cupón sea defectuoso.

Paso 5 — Prueba una hipótesis a la vez

Haz la hipótesis falsificable: "La acción de cantidad añade otros 5 dólares al descuento de cupón almacenado." Si eso es cierto, el descuento debería subir de 5 a 10 dólares tras el primer cambio de cantidad mientras el cupón sigue activo. Eliminar esa acumulación debería restaurar exactamente un descuento fijo.

No combines un cambio de cálculo con una reescritura de componente, una actualización de dependencia y una nueva regla de cupón. Quiero que el resultado de un experimento distinga una sola explicación. Un resultado exitoso tras cuatro cambios no relacionados deja la causa incierta.

Si la hipótesis falla, registra por qué y elige la siguiente a partir de la evidencia. Repetir la misma explicación sin fundamento con formulaciones ligeramente distintas no es un experimento nuevo. Deberías poder decir qué cambió en tu comprensión después de cada intento.

Paso 6 — Corrige la causa raíz

El modelo de estado apunta a una reparación focalizada: derivar el descuento fijo a partir del estado del cupón en lugar de acumularlo en los cambios de cantidad. Esto sigue la guía de React sobre evitar estado redundante. Si un valor puede calcularse a partir de las entradas actuales, una copia almacenada por separado puede desviarse.

El ejemplo de la documentación usa nombres; el mismo principio se aplica a un total de carrito derivado de los artículos y el estado del cupón.

Un patrón de reparación simplificado deriva el descuento del estado actual del cupón:

const subtotal = getSubtotal(state.quantities);

const couponDeduction = state.couponApplied ? COUPON_VALUE : 0;

const total = subtotal - couponDeduction;

Prefiero esta reparación porque un cambio de cantidad ya no acumula historial de descuento. Aun así necesitas reglas de negocio claras: si el cupón es fijo o proporcional, si puede superar el subtotal, y cómo se representa la moneda. Un cálculo de producción suele usar unidades enteras menores u otra representación monetaria deliberada.

Un cambio de cantidad debería alterar el estado del artículo y el subtotal mientras el cupón fijo permanece en 5 dólares. Inspecciona el diff real del proyecto para confirmar que el descuento acumulativo fue eliminado.

Paso 7 — Verifica, documenta y monitoriza la reparación

Repite la secuencia original y luego prueba casos cercanos: disminuir cantidad, quitar el cupón, aplicarlo de nuevo y eliminar un artículo. Preserva el fallo como una prueba de regresión. Una comprobación que simplemente monta el carrito no protege la transición de cambio de cantidad.

También deberías revisar las reglas circundantes que toca el parche. Si los totales se envían a un servidor o proveedor de pagos, verifica la concordancia en ese límite. Yo registraría la causa, los archivos cambiados, los resultados de las pruebas y el estado de release o rollback antes de cerrar un problema en producción.

Haz coincidir el método de depuración con el tipo de bug

Saber cómo depurar código de software incluye saber qué herramienta puede exponer la evidencia que falta. Un breakpoint es excelente para el estado local; es menos útil para un fallo que ocurrió ayer a través de tres servicios. Elige el método según el límite que necesites inspeccionar.

Usa breakpoints y stepping para el estado en vivo

Un breakpoint de línea pausa en una ubicación; un breakpoint condicional pausa solo cuando su condición es verdadera. La documentación de breakpoints de Chrome también cubre breakpoints de evento, DOM, solicitud y excepción. Puedes elegir el disparador más cercano al síntoma.

La visión general oficial asocia distintos síntomas a distintas condiciones de pausa.

Usa "step over" para inspeccionar el resultado de una llamada, "step into" cuando necesites su implementación, y "step out" después de revisar la función actual. Yo uso expresiones de watch para un pequeño conjunto de valores relevantes. Vigilar todo puede resultar casi tan distractor como registrar todo en logs.

La instrucción debugger de JavaScript puede solicitar una pausa cuando hay herramientas de depuración disponibles. Elimina las instrucciones de depuración temporales antes del release. Si el código desplegado está empaquetado o transpilado, revisa la configuración de source maps para que el código mostrado corresponda al código que realmente se ejecuta.

Una instrucción debugger es una ayuda de inspección. No tiene un efecto de pausa útil cuando no hay ninguna herramienta de depuración disponible.

Usa logs, tracing y profiling para evidencia distribuida

Los logs estructurados registran eventos con campos consistentes; el** tracing** sigue el trabajo a través de límites; el** profiling** examina dónde se gasta el tiempo o los recursos. Un identificador de solicitud te permite conectar eventos relacionados sin adivinar a partir de marcas de tiempo vecinas. No registres credenciales, secretos de pago ni datos personales innecesarios.

Para el carrito, los campos de diagnóstico útiles podrían ser cantidad, subtotal, estado del cupón, razón del cálculo y total resultante. Para un flujo de pedido remoto, también necesitas el importe aceptado por el servidor y el resultado. Evito afirmar que un valor del frontend establece lo que un servicio independiente procesó realmente.

Los logpoints pueden registrar un valor sin editar el código fuente ni pausar la aplicación.

Usa pruebas, aserciones y búsqueda binaria para aislar la causa

Una aserción convierte una suposición en una comprobación. Una prueba unitaria puede verificar una función de total pura; una prueba de interacción puede ejercitar la aplicación del cupón seguida de un cambio de cantidad. Necesitas ambas cuando el cálculo y la secuencia de eventos pueden fallar de forma independiente.

Elijo la prueba más pequeña que preserva el defecto, y luego añado una comprobación más amplia donde el fallo cruza un límite. Eso mantiene la prueba informativa. Un gran fallo de extremo a extremo puede decirte que el orden está mal mientras deja poco claro qué capa es la defectuosa.

Depura código generado por IA sin confiar ciegamente en el parche

Revisa el cambio generado antes de ejecutarlo

La IA para depuración de código puede ayudar a organizar hipótesis e inspeccionar código desconocido, pero las explicaciones plausibles no son evidencia de ejecución. Revisa los archivos afectados, los comandos, las dependencias, las llamadas externas y las mutaciones de datos. Deberías entender el alcance del parche antes de aceptarlo.

Separo la comprobación de tipos, el build, la ejecución de pruebas y el comportamiento observado. Responden preguntas distintas. Una prueba de reducer puede pasar mientras un manejador de botón sigue roto, así que mantén el alcance de la prueba explícito al depurar código generado por IA en tus propios proyectos.

Dale al modelo evidencia en lugar de pedirle una reescritura

Proporciona el código mínimo relevante, la discrepancia exacta, la reproducción, el entorno y el invariante. Para este carrito, el invariante es "el cupón fijo de 5 dólares se aplica una vez, sin importar los cambios de cantidad." Pide una explicación priorizada y el cambio más pequeño que pueda probarla.

Una solicitud focalizada podría ser: "Rastrea cómo cambia couponDeduction tras SET_QUANTITY. Explica por qué el subtotal de 78 dólares se convierte en 68 dólares. Propón un parche mínimo que mantenga el cupón fijo en 5 dólares, y añade una prueba para aplicar el cupón antes de cambiar la cantidad." Le das al modelo algo sobre lo que razonar y a ti algo que puedas verificar.

Inspecciona el diff y verifica de forma independiente

Lee la diferencia propuesta antes de aceptar un resumen tranquilizador. ¿La reparación eliminó el descuento acumulativo en la acción de cantidad, o solo ocultó su consecuencia en la pantalla? ¿Cambió el importe del cupón, introdujo un paquete o alteró un componente no relacionado?

Quiero pruebas que fallen contra el defecto y pasen contra la reparación, conservando los comandos y la salida. También deberías volver a ejecutar la reproducción original. Una prueba generada puede afirmar la expectativa equivocada con la misma seguridad con la que código de aplicación generado puede calcular un total incorrecto.

Depura una app de Enter Pro desde la vista previa hasta el código

La Demo de Depuración de Cupón muestra cómo depurar código de software en un proyecto controlado de Enter Pro. Seis capturas siguen el prompt, el plan, la vista previa defectuosa, la solicitud de reparación y la vista previa reparada. El defecto se sembró deliberadamente para este ejercicio.

Fija una regla antes de construir

El prompt fija los precios en 24, 18 y 12 dólares, inicia cada cantidad en uno, y excluye envío e impuestos. La regla es simple: un cupón activo descuenta exactamente 5 dólares. Solicita primero la versión defectuosa para poder preservar el fallo antes de la reparación.

Prompt de build de Enter Pro: siembra deliberadamente un segundo descuento de 5 dólares tras un cambio de cantidad.

El plan predice 54 dólares inicialmente, 49 dólares tras aplicar el cupón, y un total mostrado de 68 dólares frente a los 73 dólares correctos tras aumentar la cantidad de la tetera. Un plan registra el comportamiento previsto; la vista previa aporta la siguiente evidencia.

El plan del proyecto registra los precios, los totales esperados y el defecto de acción de cantidad planificado.

Captura el fallo en la vista previa

Con todas las cantidades en uno y el cupón activo, la vista previa muestra un subtotal de 54 dólares, un descuento de 5 dólares y ambos totales en 49 dólares. Aumentar la cantidad de la tetera a dos eleva el subtotal a 78 dólares, pero el descuento se convierte en 10 dólares. Los 68 dólares mostrados y los 73 dólares calculados de forma independiente exponen la discrepancia.

Antes del cambio de cantidad: subtotal 54 $, descuento de cupón 5 $, totales mostrado y correcto ambos en 49 $.

Tras aumentar la cantidad de la tetera a dos: subtotal 78 $, descuento 10 $, mostrado 68 $, correcto 73 $.

El plan visible almacena couponDeduction. APPLY_COUPON lo fija en 5 dólares; SET_QUANTITY añade otros 5 dólares cuando el cupón está activo. Esa ruta de estado planeada coincide con el aumento de descuento observado. Inspecciona el código del reducer correspondiente antes de parchearlo.

Solicita una reparación focalizada

La solicitud de reparación conserva el proyecto, los productos y la regla del cupón. Pide una prueba de regresión que falle antes del parche y pase después, los nombres de archivo realmente cambiados y el diff, los comandos exactos, y cualquier comprobación que no pudiera ejecutarse. Esto da al agente un invariante específico que proteger.

El prompt de reparación pide un cambio mínimo y evidencia de regresión real, mientras el fallo 68/73 permanece visible.

Verifica la reparación en el nivel correcto

La captura final etiqueta el defecto del cupón como reparado y dice que el descuento ahora se deriva del estado del cupón. Su vista previa está reiniciada: cada cantidad es uno, el cupón está inactivo, y ambos totales son 54 dólares. Esto captura la línea base reparada; no muestra el total reparado de 73 dólares tras un cambio de cantidad.

Vista previa reparada en estado reiniciado: ambos totales en 54 $. El informe identifica por separado comprobaciones de UI no ejecutadas.

El informe cita una captura de log de prueba npm anterior a la reparación con código de salida 1. La captura no muestra las ejecuciones completas en bruto fallidas y exitosas ni el diff real. También indica que las pruebas cubren las funciones de reducer y total, sin entorno jsdom y Testing Library para pruebas de UI/DOM.

El botón Aplicar está deshabilitado mientras el cupón está activo, así que la reaplicación es una comprobación a nivel de reducer. Los anchos móviles y el estilo oscuro también quedan marcados como no verificados. Para terminar la verificación, reinicia el carrito reparado y repite 54 $ → 49 $ → 73 $ dos veces, luego comprueba las disminuciones y la eliminación del cupón. Conserva el diff y la salida completa de regresión.

Escala el bug y cierra con evidencia

Escala cuando el riesgo supera el valor de otro experimento

Escala cuando el defecto implique pagos, pérdida de datos, exposición de seguridad, comportamiento inseguro o un sistema que no puedas inspeccionar. Aún puedes recopilar evidencia no invasiva, pero el responsable necesita decidir sobre la contención y el release. Yo no probaría un parche de cupón especulativo contra transacciones reales de clientes.

Transfiere un paquete de evidencia reproducible

Un traspaso debería incluir la versión defectuosa, la reproducción, el resultado esperado y real, los logs relevantes, las hipótesis probadas y la mitigación actual. Añade identificadores de solicitud y timing cuando el fallo cruce servicios. Estás transfiriendo el estado de la investigación, no simplemente asignando una queja vaga.

Completa la checklist de depuración de código

Antes del cierre, confirma la causa, el diff focalizado, la reproducción original, la protección de regresión, las rutas adyacentes y el estado de despliegue. Elimina los diagnósticos temporales o hazlos seguros e intencionales. También registro cualquier comprobación que quede sin resolver para que un futuro revisor no confunda el silencio con una aprobación.

El cierre conecta la causa y la reparación con la evidencia conservada. Un build exitoso solo cubre una parte de ello.

Reflexiones finales: cómo depurar código de software de forma confiable

No necesitas una reescritura dramática para depurar código de forma efectiva. Necesitas una discrepancia precisa, una reproducción preservada y evidencia que acote la causa. En el ejercicio del carrito, la pista decisiva es que el descuento sube de 5 a 10 dólares cuando cambia la cantidad.

Mi proceso preferido para depurar código generado por IA es inspeccionar primero, cambiar una sola cosa relevante y verificar después la transición original. La demo de Enter Pro hace visible la aritmética y el cambio de estado, mientras su informe de reparación distingue las comprobaciones de cálculo de las comprobaciones de UI no ejecutadas. Conserva juntos el diff, la salida de regresión y los resultados repetidos de la vista previa para que la siguiente persona pueda evaluar la reparación.

Prueba este flujo de trabajo en Enter Pro: preserva un caso de fallo, solicita una reparación focalizada y revisa la evidencia antes de aceptarla.

Preguntas frecuentes

¿Cuál es lo primero que hay que hacer cuando el código falla?

Anota el comportamiento esperado y el real, preserva la entrada que falla y establece una reproducción. Si el defecto está causando daño en producción, puede que la contención deba ocurrir antes de seguir investigando.

¿Cómo depuro código que falla solo a veces?

Registra las transiciones de estado, el timing, los reintentos y los identificadores a lo largo de intentos repetidos. Compara las ejecuciones fallidas y exitosas bajo condiciones similares. Una sola ejecución exitosa no demuestra que una causa intermitente haya desaparecido.

¿Debería usar instrucciones print o un depurador?

Usa un depurador cuando necesites control de flujo en vivo y valores locales. Usa logs para evidencia remota, histórica o sensible al timing. Las instrucciones print temporales son útiles cuando responden a una pregunta concreta y se eliminan después.

¿Puede la IA depurar código por mí?

La IA para depuración de código puede sugerir causas, inspeccionar código relevante y proponer pruebas o parches. Aun así necesitas revisar el cambio y verificar el resultado. Trata las explicaciones generadas y las comprobaciones reportadas según la evidencia disponible.

¿Cómo depuro código sin empeorar el bug?

Preserva el estado original, trabaja en un entorno aislado y cambia una variable relevante a la vez. Mantén una vía de rollback para los cambios en producción y evita acciones de diagnóstico que mutilen datos reales de clientes.

¿Por qué vuelve un bug después de haberlo corregido?

El parche puede haber ocultado el síntoma, pasado por alto otra ruta, o no haber logrado preservar el caso en una prueba de regresión. Compara el nuevo fallo con la evidencia original antes de asumir que tiene la misma causa.

¿Cómo puedo usar Enter Pro para depurar código?

Mantén la vista previa defectuosa y la reparación en un solo proyecto. Dale a Enter Pro la secuencia de acciones, los totales esperados y reales, y la regla que el parche debe preservar. Pídele que inspeccione el cálculo, haga un cambio focalizado y conserve evidencia de regresión. Revisa el diff real y repite la secuencia tú mismo.

¿Qué debería verificar después de que Enter Pro repare un bug?

Repite el fallo original y las rutas cercanas, y luego inspecciona los resultados completos de las pruebas. En esta demo, la vista previa reparada debe mostrar 73 dólares tras aplicar el cupón y aumentar la cantidad de la tetera a dos. La captura de reinicio en 54 dólares por sí sola no puede establecer eso. Trata las pruebas de reducer, las pruebas de interacción de UI y las comprobaciones de build como evidencia separada.