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

Soy un Programador Junior (4 meses de experiencia profesional hasta el momento) trabajando en una aplicación móvil multiplataforma (equipo de 1 persona, así que soy yo mismo).

Tengo un error en este programa / aplicación que es bastante grande (30 archivos de encabezado diferentes, cada uno con su propio archivo cpp también). He estado tratando de rastrear exactamente lo que está sucediendo con el error y también para solucionarlo (incluso intenté usar algunos hacks para que funcione) pero de aproximadamente una docena o más de soluciones (ideas que tengo sobre qué está causando el problema) ) No se me ocurrió nada que me haya llevado a rastrear exactamente qué es el error o solucionarlo.

¿Tiene algún consejo para un programador junior de algunas técnicas amplias (salir a correr, imprimir todo mi código en papel y revisarlo con un bolígrafo, etc.) que podría usar para ayudarme con este error?

Para dar un poco más de contexto a mi error; involucra la API multiplataforma Mosync, cuando realizo una secuencia específica de acciones, la pantalla actual no se vuelve a dibujar (y parece) que la pantalla mostrada anteriormente todavía está recibiendo los eventos de puntero / tecla y no la pantalla actual.

Secuencia específica:
- Pantalla de menú visualizada - haga clic en "Mostrar botón de órdenes previas"
- Pantalla de órdenes previas visualizada - haga clic en "Cargar archivo" y luego haga clic en el botón de menú y abra la pantalla de
entrega - Pantalla de entrega visualizada - haga clic en el botón de menú y abra Pantalla de
compra - Pantalla de compra visualizada - Error aquí, la entrada a esta pantalla no se muestra / reacciona, ListViews no se desplaza, los botones no reaccionan a los clics, las celdas ListView no responden a los clics

También me encantaría tener un par de ojos diferentes que revisen mi trabajo y señalen el error, pero como dije que soy un equipo de 1, mi jefe me dirige, es dueño de la compañía y tiene las ideas para una aplicación, pero lo hace No conozco c ++ ni ninguno de los idiomas recientes (¿cobal? Creo que es todo). ¿Algún consejo sobre cómo obtener un segundo par de ojos sin violar / mostrar el código / propiedad intelectual de la empresa?

... y no abandonar esta pasantía remunerada no es una opción, el contrato dice que si me voy antes de los 6 meses de un contrato de 12 meses, tal vez deba pagar el 30% de mi salario anual

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

Editar:

Y si está sentado al final de su ingenio tratando de corregir el error y publicando aquí con la esperanza de obtener algunos consejos brillantes, aléjese . Ve a despejarte y vuelve más tarde (preferiblemente mañana o después del fin de semana). He pasado muchas veces que he pasado un día entero buscando una solución a un problema en particular solo para alejarme, regresar al día siguiente con la cabeza despejada y encontrarlo en diez minutos.

La depuración tiene más que ver con aislar y comprender exactamente cuál es el problema (en comparación con la aplicación de una solución)

Una cosa que debe tener cuidado al depurar es si comienza a ver que está saltando tras diferentes teorías, ya que a menudo esto lleva mucho más tiempo y no elimina sistemáticamente los posibles problemas.

Por lo general, la mejor manera de depurar este tipo de situaciones es el enfoque sistemático aburrido dividiendo su sistema en pequeños pedazos y haciendo que cada uno trabaje de forma aislada y siga 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 el cerebro sano al intentar depurar una pieza compleja de software.

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

1. Tenga en cuenta que es solo código, y en algún lugar hay un error (no es solo magia negra) que PUEDE corregir.
2. Tomar un descanso.
3. Revise el código muy lentamente, analice cada paso y asegúrese de comprenderlo y lo que está haciendo, sin pasar por alto nada.
4. Obtenga un segundo par de ojos para ver el problema.
5. Ve a dormir y olvídate de eso hasta mañana (aclara tu cabeza), ven con una nueva perspectiva).
6. Imprima su código y analice cada línea, tome notas en los márgenes y comprenda cada implicación de cada línea.
7. Si no es un error crítico, pero está causando errores que el usuario no necesita saber, ¡(avergonzado pero honestamente) atrapé el error y me lo tragué ! Si no es peligroso y no puede encontrar la causa, a veces simplemente lo atrapa y no le permite al usuario saber que sucedió algo. 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 escapará. :-)

Por lo general, tengo este enfoque al resolver errores.

1. Crea un bonito paso a paso para reproducir el error
2. Simplifica el paso a paso
3. ¿En qué parte del código se produce el error? ¿Qué funciones involucra?
4. Qué ruta elige el código cuando ocurre el error, la cadena de llamada.
5. Concéntrese en la ubicación, cuando está bien, cuando no lo está. Luego repita esto mucho hasta que encuentre exactamente el lugar donde ocurre el error.
6. ¿Por qué pasó esto?

En este punto, por lo general, es bastante claro lo que ha sucedido, ya que aprendo mucho en el proceso de enfocarme en el problema, así que sé qué hacer. O tengo una pregunta bastante centrada 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 están destinados a verificar las suposiciones sobre el error / error y luego seguir un proceso de depuración para localizar el error (a veces examinando el entorno alrededor del error y otras directamente en el código).

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

Como otros dijeron 1) ser capaz de reproducirlo de manera confiable y 2) avanzar en un depurador hasta el punto en que ocurra.

Si no puedo hacer eso, por alguna razón, tengo otros dos métodos que requieren tener una versión diferente del código que no exhiba el error.

1. Ejecute ambas versiones del código de lado a lado en depuradores. Déjelos avanzar hasta que el malo haga algo diferente del bueno.

2. Alterne las versiones buenas y malas del código. Tenga una diferencia o alguna otra lista de las diferencias entre las versiones. Luego, cambie gradualmente el código de cualquiera de las versiones para que coincida más estrechamente con la otra. Si el malo se vuelve bueno, o el bueno se vuelve malo, retrocedo el cambio y hago un cambio más pequeño. De esta manera me encuentro con el error. Lo considero como "llegar a 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 tanta información como pueda conseguir, como un volcado de pila, cuando no suceda. Así que me aseguro de que puedo obtener esos diagnósticos, espero que ocurra el problema y espero tener suficiente información para encontrarlo.

Si se le asignó hacer el trabajo en la mano como programador junior, hay al menos una persona que creía que era capaz de manejarlo todo usted mismo.

Luego, antes de pedir ayuda a sus superiores, escriba en una hoja de papel, la lista de pasos / métodos que siguió para rastrear el error, hasta dónde llegó, por qué renunció a cada método y qué aprendió. 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 se vuelva cegadoramente obvio. Si lo hace, simplemente tiene que seguir lo que se reveló para reproducir el error e intentar solucionarlo. Si no es así, tiene una base sobre la cual puede hablar con sus superiores. Si solicita su ayuda sin mostrar lo que ha hecho, podrían tener una impresión negativa en usted.

Pero, si aclaras tu mente, regresas después del fin de semana, podrías resolverlo en poco tiempo, sin la ayuda de nadie. Pasa todo el tiempo.

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

Si no puede reprogramarlo, entonces tiene un problema, ¿cómo confirma que lo ha solucionado? Ponga el código de depuración y déjelo allí. Finalmente, pregúntese, ¿está "Cerrado: DNR" es una opción válida? (Hizo / No pudo reprogramar). En los negocios, eventualmente es una decisión de costo / beneficio.

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

Tómese 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 lo ayude.

Muchas buenas respuestas aquí. Algunos otros consejos:

Las IU rara vez viven aisladas. Cree un programa de prueba con el conjunto mínimo de características 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. ¿Todavía puedes reproducir el problema? Si es así, es probable que el problema esté en su estructura o marco de la interfaz de usuario. Verifique su estructura de UI, 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 marco de la interfaz de usuario en sí; no llegue a esa conclusión, pero no lo descarte directamente. Una prueba rápida es actualizar su versión de Mosync y verificar si los síntomas persisten.

De lo contrario: ¿Qué queda en su programa de prueba? Comprenda todos los componentes de lo que queda, particularmente los hilos en ejecución. ¿Algo que hace el mantenimiento de la 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 funciona con algunos de estos componentes (posiblemente detrás de escena)? ¿De qué operaciones en segundo plano depende la IU?

Mientras lee el código, que debería dedicar un tiempo considerable, dada la dificultad del error, tenga cuidado con algunas 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 */ }

Esa es una práctica increíblemente pobre y, como tal, es bastante común (¡mira, no se bloqueó!). Asegúrese de actualizar cualquier código que esté haciendo eso para al menos registrarlo, preferiblemente elimine por completo el manejo de excepciones falsas. (Una regla general 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, esté atento a la caída de los valores de retorno del código de error y asegúrese de que está comprobando la información del estado de error de las herramientas con las que está interactuando.

Al ver cómo su programa de prueba ahora maneja correctamente las fallas, y ha leído el registro que ha producido, pero aún así nada resalta el error, busque las interfaces que puede sondear. ¿Hay una transacción de red que debería estar sucediendo bajo las sábanas? Si es así, golpéalo con Wireshark. Transacción de base de datos? Pruebe algunos registros de consultas o compruebe el estado del servidor de la base de datos. ¿El sistema de archivos o las redes compartidas están siendo afectadas? Verifique los archivos intermedios o use un depurador para rastrear E / S. ¿E / S de hardware? Monitorear y sondear. Se empírico. La interfaz de usuario bien podría colgarse en alguna operación en segundo plano que no haya previsto.

Por último: no se asuste. Mantén la calma y realiza un seguimiento de lo que has probado. 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 por ese camino.

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

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

Paso a paso por el comportamiento de la aplicación, línea por línea. Mira los valores de las variables. Mira 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 del "recuadro negro", ¿puede obtener la fuente de bibliotecas / marcos compilados, lo que le permite avanzar a un nivel más profundo si es necesario?

¿Tiene una confirmación en su sistema de control de versiones que no produce este error? (Está utilizando el control de versiones, ¿no es así?) Si tiene ese compromiso, 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, intentar (2) examinar, comprender el comportamiento de la aplicación en detalle (3) aislar el problema haciendo que desaparezca y luego examinar y comprender el delta que te permitió hacer eso

Pero definitivamente no te quedes ahí sentado durante semanas si estás realmente atrapado. Tienes que decirle a alguien en tu organización también. Solicite ayuda donde pueda y más allá de cierto punto, ciertamente le corresponde a usted decirle a la gerencia que siente que ha topado con una barrera para progresar. Pero es probable que pueda resolver esto si lo golpea desde varios ángulos diferentes, todos enfocados en el aprendizaje y la comprensión.