Qué hacer cuando haya agotado todas las vías para corregir un error

Si puede reproducir el problema el 100% del tiempo, establezca un punto de interrupción en el último paso (lo antes posible). Si recorres toda la pila de llamadas, estoy bastante seguro de que encontrarás valores inesperados en algún lugar, o algo que debería llamarse pero no es.

Editar:

Y si estás sentado al final de tu ingenio tratando de solucionar el error y publicando aquí con la esperanza de que obtengas algunos consejos brillantes, aléjate . Vaya claro y vuelva más tarde (preferiblemente mañana o después del fin de semana). En muchas ocasiones he pasado un día entero buscando una solución a un problema en particular para irme, volver al día siguiente con la cabeza despejada y encontrarla en diez minutos.

La depuración consiste más en aislar y entender exactamente cuál es el problema (en comparación con aplicar una solución)

Una cosa que hay que tener cuidado al momento de la depuración es si empiezas a ver que estás saltando según diferentes teorías, ya que esto a menudo toma más tiempo y no elimina sistemáticamente los posibles problemas.

Por lo general, la mejor forma de depurar este tipo de situaciones es mediante el enfoque sistemático aburrido al dividir el sistema en pequeños pedazos y hacer que cada uno de ellos funcione de forma aislada y continúe agregando cada elemento de complejidad uno por uno hasta que se rompa. Entonces has aislado el problema exacto. De esta manera, puede parecer un poco tedioso y un poco más de trabajo inicial, pero elimina las variables y mantiene su cerebro sano al intentar depurar una pieza compleja de software.

Estas son solo algunas de las cosas que he hecho en el pasado, obviamente no funcionarán en todas las situaciones:

1. Date cuenta de que es solo un código, y en algún lugar hay un error (no es solo magia negra) que PUEDES arreglar.
2. Tómate un descanso.
3. Recorra el código muy lentamente, analice cada paso y asegúrese de entenderlo y de lo que está haciendo, sin pasar por alto nada.
4. Obtenga un segundo par de ojos para ver el problema.
5. Duerme y olvídalo hasta mañana (despeja tu mente), ven con una nueva perspectiva).
6. Imprima su código y analice cada línea, tomando notas en los márgenes, entendiendo cada implicación de cada línea
7. Si no es un error crítico, pero está causando errores que el usuario no necesita conocer, yo (vergüenza, pero honestamente) atrapé el error, ¡y lo tragó ! Si no es peligroso, y usted no puede encontrar la causa, a veces simplemente lo atrapa y no le dice al usuario que sucedió nada. Todo se trata de ROI para el cliente, y a veces no vale la pena.
8. Dígale al error verbalmente que va a cazarlo y matarlo. A veces se escapa. :-)

Por lo general, tengo este enfoque al resolver errores.

1. Cree un buen paso a paso para reproducir el error
2. Simplifica el paso a paso
3. ¿Dónde en el código ocurre el error? ¿Como qué funciones está involucrada?
4. ¿Qué ruta elige el código cuando ocurre el error, la cadena de llamada?
5. Enfóquese en la ubicación, cuándo está bien cuándo no. Luego repita esto mucho hasta que encuentre exactamente el lugar donde se produce el error.
6. ¿Por qué sucede esto?

En este punto, por lo general, es bastante claro lo que ha sucedido, ya que aprendo mucho en el proceso de enfoque en el problema, así que sé qué hacer. O tengo una pregunta bastante enfocada que puedo hacer en un foro.

Luego trato de solucionar el problema y utilizo el paso a paso que creaste en el paso uno para verificar si el error está solucionado.

Todos los consejos anteriores son excelentes, y gran parte de ellos tienen como objetivo verificar las suposiciones acerca del error / error y luego seguir un proceso de depuración para localizar el error (algunas veces examinando el entorno alrededor del error y otras directamente en el código).

Este enfoque no siempre funcionará, independientemente de que dependa de su antigüedad o experiencia. A veces solo necesitas otro par de ojos sobre el problema. Encuentre a alguien para que revise el problema o la sesión de depuración con usted; a menudo, solo con leer el código lo llevará al error.

Como han dicho otros 1) ser capaz de reproducirlo de manera confiable, y 2) avanzar en un depurador hasta el punto en que sucede.

Si no puedo hacerlo, por el motivo que sea, tengo otros dos métodos que requieren tener una versión diferente del código que no presenta el error.

1. Ejecute ambas versiones del código en paralelo debajo de los depuradores. Sígalos hasta que el malo haga algo diferente al bueno.

2. Alterne la ejecución de las versiones buenas y malas del código. Tenga un diff o alguna otra lista de las diferencias entre las versiones. Luego, cambie de manera incremental el código de cualquiera de las dos versiones para que coincida más con la otra. Si el malo se vuelve bueno o el bueno se vuelve malo, yo desalojo el cambio y hago un cambio menor. De esta manera me encuentro en el error. Lo considero como "meterse en ambos lados del problema y trabajar hacia el centro". Este método no requiere un depurador.

Si el problema es difícil de reproducir, entonces necesito toda la información que pueda obtener, como un volcado de pila, cuando sucede . Así que me aseguro de poder obtener esos diagnósticos, esperar a que ocurra el problema y espero tener suficiente información para encontrarlo.

Si se te asignó hacer el trabajo en mano como programador junior, hay al menos una persona que creía que eras capaz de manejarlo todo por ti mismo.

Luego, antes de pedir ayuda a sus superiores, escriba en un papel de desecho, la lista de pasos / métodos que tomó para rastrear el error, hasta qué punto lo siguió, por qué abandonó cada método y qué has aprendido en cada intento Además, resuma lo que ha aprendido sobre el proyecto hasta ahora.

Lo más probable es que, cuando termine de escribir esto, lo que se puede hacer sea algo obvio. Si lo hace, simplemente tienes que seguir lo que se reveló para reproducir el error e intentar solucionarlo. Si no es así, tienes una base sobre la cual puedes hablar con tus superiores. Si solicita su ayuda sin mostrar lo que ha hecho, es posible que le causen una impresión negativa.

Pero, si te aclaras la cabeza y vuelves después del fin de semana, podrás resolverlo en poco tiempo, sin la ayuda de nadie. Sucede, todo el tiempo.

Necesitamos saber qué tan difícil es reproducirse, ya que el método es bastante diferente. Para un defecto reproducido de manera confiable, automatice causando el defecto. Use depuradores y rastreos de depuración (los rastros tienen el menor impacto en los defectos de tipo de condición de carrera). Obtener metódico. Un paso a la vez, cada paso proporciona más información, incluso si confirma lo que ya sabe. Si obtiene un resultado sorpresa, deténgase, entiéndalo al 100% antes de continuar. Es dolorosamente lento, pero siempre te lleva al resultado final si le das suficiente tiempo.

Si no puede presentar un informe, entonces tiene un problema, ¿cómo confirma que lo ha solucionado? Poner en código de depuración y dejarlo allí. Finalmente, pregúntese, ¿está "Cerrado: DNR" es una opción válida? (Hizo / No pude reporduce). En los negocios, eventualmente es una decisión de costo / beneficio.

No asuma que sus bibliotecas son correctas, confirme que lo son.

Tome un descanso, sea pragmático sobre el costo frente a la necesidad de arreglarlo y, sobre todo, pídale a alguien que se siente a su lado y le ayude.

Muchas buenas respuestas aquí. Algunos otros consejos:

Las interfaces de usuario rara vez viven aisladas. Cree un programa de prueba con el conjunto mínimo de funciones necesarias para reproducir el error. Si la interfaz de usuario está bien diseñada, debería poder desacoplar los componentes de la interfaz de usuario que están fallando y ejecutarlos de forma aislada en un programa de prueba. ¿Aún puedes reproducir el problema? Si es así, el problema es probable en la estructura o el marco de su interfaz de usuario. Revise la estructura de su interfaz de usuario, especialmente tenga cuidado con los elementos invisibles. Intente saber exactamente qué sucede cuando hace clic en ese ListView y no responde. ¿Qué controladores de eventos se invocan? Tenga en cuenta que puede haber errores en el propio marco de la interfaz de usuario: no llegue a esa conclusión, pero no lo descarte por completo. Una prueba rápida es actualizar su versión de Mosync y verificar si los síntomas se mantienen.

Fallando en eso: ¿Qué queda en tu programa de prueba? Comprenda todos los componentes de lo que queda, particularmente cualquier subproceso en ejecución. ¿Algo haciendo mantenimiento de base de datos en segundo plano? Una cola de archivos de algún tipo? ¿Código de monitoreo de comportamiento del usuario de la NSA? ¿La interfaz de usuario está trabajando con algunos de estos componentes (posiblemente entre bastidores)? ¿De qué operaciones de fondo depende la interfaz de usuario?

Mientras lee el código, en el que debería dedicar un tiempo considerable, dada la dificultad del error, tenga cuidado con las malas prácticas que podrían estar ocultando su error. Específicamente, ¿ves algo de esto?

try {
    SaveTheWorld();
} catch (std::exception& ex) { /* oh it didn't work, let's just ignore it */ }

Es una práctica increíblemente deficiente y, como tal, es bastante común (oye, ¡no se estrelló!). Asegúrese de actualizar cualquier código que esté haciendo eso para, al menos, registrarlo, preferiblemente elimine por completo el manejo de las falsas excepciones. (Una regla de oro es que si no sabe cuál es la excepción, no está preparado para manejarlo). Si está interactuando con las API de estilo C, observe los valores de retorno de códigos de error y asegúrese de que está comprobando la información de estado de error de las herramientas con las que interactúa.

Al ver cómo su programa de prueba ahora está manejando correctamente las fallas, y ha leído el registro que ha producido así, pero aún así, nada resalta el error, busque las interfaces que pueda sondear. ¿Hay una transacción de red que debería estar sucediendo bajo las coberturas? Si es así, golpéalo con Wireshark. Transacción de base de datos? Intente un registro de consultas o verifique el estado del servidor de la base de datos. ¿Un sistema de archivos o recursos compartidos de red siendo golpeados? Verifique los archivos intermedios o use un depurador para rastrear la E / S. Hardware I / O? Monitor y sonda. Se empírico. La interfaz de usuario podría colgarse en una operación en segundo plano que no haya anticipado.

Por último: No se asuste. Mantente fresco, y realiza un seguimiento de lo que has intentado. Si aún no puede encontrarlo, tendrá que convertirse en un "problema conocido" para ser rastreado en un día lluvioso. Querrá mucho material para justificar esa decisión si tiene que ir de esa manera.

En el esquema de las cosas, ¡los errores reproducibles son (relativamente) fáciles! ¿Por qué? Porque siempre puedes cortar el código al mínimo hasta que el error desaparezca, y luego volver a trabajar para averiguar qué código lo causa. Así que ese es un método. Es reproducible, tienes la criatura bajo tu control. Puedes empujarlo, y experimentar con él. Incluso puedes diseccionarlo si quieres.

Su primer objetivo es comprender por qué el error está ocurriendo en el código su . No intentes arreglarlo inicialmente. Solo trata de entenderlo . Si intentas solucionarlo sin comprenderlo, estarás pirateando y probablemente introducirás deuda técnica , incluso si lo resuelves.

Paso a través del comportamiento de la aplicación, línea por línea. Mira los valores de las variables. Observa el flujo de control. ¿Dónde se desvía primero el comportamiento de lo que su comprensión le dice que debería ser? ¿Entiendes cómo el sistema operativo envía eventos a tu aplicación? Si se ve obstaculizado por el problema de la "caja negra", ¿puede obtener la fuente de las bibliotecas / marcos compilados, lo que le permite avanzar a un nivel más profundo si tiene que hacerlo?

¿Tiene un compromiso en su sistema de control de versiones que no produce este error? (Está utilizando el control de versiones, ¿no es así?) Si tiene tal confirmación, puede hacer una búsqueda binaria en el historial para averiguar exactamente dónde se introdujo el error.

Sus objetivos deben ser (1) comprender: determinar la causa y, para ello, tratar de (2) examinar, comprender en detalle el comportamiento de la aplicación (3) aislar el problema haciendo que desaparezca y luego examinar y comprender el delta que te permitió hacer eso

Pero definitivamente no te sientes allí por semanas si realmente estás atascado. Tienes que decirle a alguien en tu organización también. Solicite ayuda donde pueda y más allá de cierto punto, sin duda le incumbe a usted decirle a la gerencia que siente que se ha topado con una barrera para el progreso. Pero es probable que puedas resolver esto si lo golpeas desde varios ángulos diferentes, todos enfocados en el aprendizaje y la comprensión.