Como profesional del software, ¿cómo se maneja cuando no puede resolver algo o volver a crear el problema, como un error oscuro que le pagan por solucionar? ¿La recreación del error es un paso necesario para la resolución de problemas?

Los errores son fáciles de solucionar, encontrarlos es el problema.

¿La recreación del error es un paso necesario para la resolución de problemas?

No es necesario, pero hará tu vida 100 veces más fácil si puedes.

Con los lenguajes modernos, con un bloqueo, generalmente (no siempre) obtendrá un seguimiento de pila decente, que lo llevará a la línea de código en cuestión, a partir de ahí, a menudo puede ver cuál es el problema.

Algunos errores son tan oscuros que solo ocurren en las circunstancias más particulares. He tenido un error que me llevó alrededor de 10 años solucionarlo, ya que solo ocurrió ocasionalmente para un puñado de usuarios.

Como regla, ** nunca ** soluciono un error que no puedo reproducir.

¿Por qué?
El software en el mundo real es algo muy complejo, con una interdependencia alucinante. Como humano, me di cuenta de que podía mirar algo durante días y aún no entender ** todas ** las implicaciones de una determinada línea de código.

¿Qué sucede si lo soluciono en base a una estimación aproximada?
2 o más errores nuevos y más obvios 🙂
Afirmo que solucioné un error y sucede nuevamente en 2 meses: pierdo reputación.

Entonces, ¿cómo se solucionan los errores que son oscuros, difíciles de reproducir y que ocurren una vez de cada 10 intentos de reproducción?
Mire el estado de error cuidadosamente. Obtenga más información si no tiene suficiente. Ha habido ocasiones en las que he emitido una “solución temporal” que solo aumentó el registro en el área sospechosa para que sepa lo que realmente estaba sucediendo. Me he sentado junto a un usuario hasta por una hora para ver cómo ocurre un error.

Una vez armado con datos, trato de localizar la línea exacta de código que falló y trabajar al revés sobre cómo podría fallar. Esto es laborioso y puedo usar varias páginas de notas con estados variables y similares.

Luego termino con varias posibilidades sobre cuál podría ser la causa. Luego, emito otra “solución temporal” al iniciar sesión en lo que creo que es la fuente del error.

Luego, con estos datos reales, trato de reproducir el error y producir una solución final.

Toma tiempo … Debe poder hablar con la gerencia y explicar la causa. Si no cooperan, entonces la única opción es eliminar todas las pruebas de que se produjo un error (broma, por favor, no haga esto).

Nota: si el error es oscuro, casi siempre es una “condición de carrera”

Si no puede recrear el problema, entonces realmente no sabe si ha solucionado el error o no. Esto lo hace realmente difícil. Sin embargo, a veces tales errores pueden corregirse estadísticamente .

¿Qué significa esto? Un escenario típico (para mí) es que el programa se bloquea en alguna prueba unitaria automática, digamos una vez al mes. Después de una investigación prolongada, encuentro algunos lugares sospechosos o claramente con errores que pueden tener algo que ver con el error, o tal vez no. Reescribo los lugares sospechosos, corrijo los errores obvios, limpio el código, agrego algunas comprobaciones defensivas, pongo más registros, etc. Pero realmente no puedo estar seguro de si el error original se solucionó o no.

La única forma de estar seguro es esperar. Si el error no vuelve a aparecer durante, digamos, un año, entonces tengo la confianza suficiente para reclamar que se solucionó y marcar el ticket como resuelto.

El primer paso es reproducirlo en un entorno controlado, el resto suele ser sencillo.