¿Es razonable insistir en reproducir todos los defectos antes de diagnosticarlos y corregirlos?

  

¿Es razonable insistir en reproducir todos los defectos y depurarlos antes?   ¿Lo diagnosticas y lo arreglas?

No, definitivamente no lo es. Eso sería una política estúpida.

El problema que veo con tu pregunta y tu propuesta es que no hacen una distinción entre

• informes de errores
• fallas ( errores )
• errores (también a veces llamados errores )

Un informe de error es comunicación sobre un error. Te dice que alguien piensa que algo está mal. Puede o no ser específico acerca de lo que se supone que está mal.

Un informe de error es evidencia de un error.

Un error es un incidente de que algo va mal. Un mal funcionamiento específico, pero no necesariamente con ninguna pista sobre lo que puede haberlo causado.

Un error puede ser causado por un error.

Un error es una causa de fallas; algo que puede (en principio) cambiarse para evitar que las fallas que causa ocurran en el futuro.

A veces, cuando se informa de un error, la causa queda inmediatamente clara. En tal caso, la reproducción del error sería absurda. En otras ocasiones, la causa no está clara en absoluto: el informe de error no describe ningún error en particular, o lo hace, pero el error es tal que no proporciona una pista sobre cuál podría ser la causa. En tales casos, siento que su consejo está justificado, pero no siempre: uno no insiste en estrellar un segundo cohete espacial de $ 370 millones antes de aceptar investigar lo que causó que la primera fallara (un error en particular en el software de control).

Y también hay todo tipo de casos en el medio; por ejemplo, si un informe de error no prueba, sino que solo sugiere, que un problema potencial que ya conocía podría jugar un papel, esto podría ser un incentivo suficiente para que lo examine más detenidamente.

Entonces, si bien insistir en la reproducibilidad es sensato para los casos más difíciles, no es prudente imponerlo como una política estricta.

Como con todo lo demás en el desarrollo de software, la respuesta correcta es un compromiso.

En teoría, nunca debes tratar de corregir un error si no puedes probar que existe. Si lo hace, puede hacer que realice cambios innecesarios en su código que, en última instancia, no resuelven nada. Y probarlo significa reproducirlo primero, luego crear y aplicar un arreglo, luego demostrar que ya no sucede. Su instinto aquí lo está guiando en la dirección correcta: si desea estar seguro de haber resuelto el problema de su cliente, necesita saber en primer lugar lo que lo causó.

En la práctica, eso no siempre es posible. Quizás el error solo se produce en grupos grandes con docenas de usuarios que acceden a su código simultáneamente. Quizás haya una combinación específica de operaciones de datos en conjuntos específicos de datos que desencadena el error y no tiene idea de qué es eso. Quizás su cliente ejecutó el programa de forma interactiva sin parar durante cientos de horas antes de que se manifestara el error.

En cualquiera de esos casos, existe una gran posibilidad de que su departamento no tenga tiempo o dinero para reproducir el error antes de comenzar a trabajar. En muchos casos, es mucho más obvio para usted, el desarrollador, que hay un error en el código que le señala a la situación correcta. Una vez que hayas diagnosticado el problema, puedes volver y reproducirlo. No es lo ideal, pero al mismo tiempo, parte de su trabajo como desarrollador senior es saber cómo leer e interpretar el código, en parte para localizar este tipo de errores ocultos.

En mi opinión, te estás enfocando en la parte equivocada de la pregunta. ¿Qué pasa si finalmente no puede reproducir el error en cuestión? No hay nada más frustrante para un cliente que escuchar "sí, sabemos que bloqueó el programa pero no podemos reproducirlo, así que no es un error". Cuando su cliente escucha esto, lo interpretan como "sabemos que nuestro software está defectuoso, pero no podemos molestarnos en solucionarlo y corregir los errores, así que simplemente cruce los dedos". Si es mejor cerrar un error reportado como "no reproducible", o cerrarlo como "no reproducible, pero hemos hecho algunos cambios razonables para tratar de mejorar la estabilidad"?

A menos que el error sea evidente, obvio y trivial, con un mensaje de error muy específico, etc., a menudo es muy difícil corregir un error si el usuario o el mantenedor no pueden replicarlo.

Además, ¿cómo les demostrarías que el error está solucionado si no puedes replicar los pasos?

El problema con su caso es que el usuario tampoco sabe cómo ocurrió el error, es decir, en qué pantalla se realiza la operación. Simplemente tienen el registro.

Creo que tu punto es razonable. Si usted tuviera poderes psíquicos , posiblemente no estaría trabajando por un salario.

Creo que debería decirle a sus jefes que, sin poder replicar el error, tardaría un tiempo desconocido en averiguarlo, y no tiene ninguna garantía que lo harás.

El problema será cuando algún compañero suyo encuentre el error por pura suerte y lo arregle.

Llevémoslo al extremo y supongamos que has encontrado el error mucho antes: en tu código, mientras lo escribías. Entonces no tendrías reparos en solucionarlo allí mismo. - Ves una falla lógica en el código que acabas de escribir, no hace lo que querías que hiciera. No sentirías la necesidad de configurar un entorno completo para demostrar que en realidad es un error.

Ahora llega un informe de error. Hay varias cosas que puedes hacer. Uno de ellos es volver al código y releerlo. Ahora, suponga que en esta segunda lectura, inmediatamente encuentra el error en el código; simplemente no hace lo que usted quería que hiciera y no se dio cuenta cuando lo escribió. Y , ¡explica perfectamente el error que acaba de llegar! Usted hace la corrección. Te tomó veinte minutos.

¿Eso solucionó el error que causó el informe de error? No puede estar 100% seguro (puede haber dos errores que causan esta misma cosa), pero probablemente lo hizo.

Otra cosa que podría hacer es reproducir la configuración del cliente tan bien como pueda (trabajo de unos días) y, finalmente, reproducir el error. En muchos casos, hay problemas de tiempo y de concurrencia que significan que no puede reproducir el error, pero puede intentar mucho tiempo y, a veces, ver que sucede lo mismo. Ahora empieza a depurar, encuentra el error en el código, póngalo en el entorno y vuelva a intentarlo muchas veces. Ya no ves que se produce el error.

¿Eso solucionó el error que causó el informe de error? Aún no puede estar seguro al 100%: uno, puede que haya visto un error completamente diferente al del cliente, dos, tal vez no lo intentó con la frecuencia suficiente, y tres, tal vez la configuración sea ligeramente diferente y es arreglado en este sistema, pero no del cliente.

Por lo tanto, es imposible obtener certeza en cualquier caso. Pero el primer método es mucho más rápido (también puede darle al cliente un parche más rápido), es mucho más barato y, si encuentra un error de codificación claro que explica el síntoma, es más probable que encuentre el problema también.

Así que depende. Si es barato configurar un entorno de prueba (o mejor: una prueba automatizada que muestra el problema), hágalo. Pero si es caro y / o las circunstancias en las que se muestra el error son impredecibles, siempre es mejor tratar de encontrar el error leyendo el código primero.

Leyendo la pregunta, no veo ninguna oposición fundamental entre tu posición y la de tu equipo.

• Sí, debe esforzarse al máximo para reproducir el problema que se produce en la configuración del cliente. Pero el mejor esfuerzo significa que debe definir un cuadro de tiempo para eso, y puede que no haya suficientes datos en el registro para reproducir realmente el problema.

  Si es así, todo depende de la relación con este cliente. Puede ir desde que usted no tenga nada más de él, hasta que pueda enviar un desarrollador en el sitio con herramientas de diagnóstico y capacidad para ejecutarlos en el sistema que falla. Por lo general, estamos en un punto intermedio y, si los datos iniciales no son suficientes, hay formas de obtener más.

• Sí, un desarrollador senior debe poder leer el código y es probable que encuentre la razón del problema después del contenido del registro. En realidad, a menudo es posible escribir algunas pruebas unitarias que presentan el problema después de leer cuidadosamente el código.

  La escritura de éxito en tales pruebas unitarias es casi tan buena como la reproducción del entorno funcional de ruptura. Por supuesto, este método tampoco es una garantía de que encontrarás algo. Comprender la secuencia exacta de eventos que llevan a la falla en algunos programas de múltiples subprocesos puede ser realmente difícil de encontrar con solo leer el código, y es probable que la capacidad de depurar en vivo se vuelva crítica.

Resumidamente, probaría para ambos enfoques simultáneamente y pediría un sistema en vivo que muestre el problema (y que demuestre que se ha corregido después) o que se realice una prueba de ruptura del problema (y que también muestre que se solucione después de la corregir).

Intentar simplemente arreglar el código y enviarlo en la naturaleza, parece muy arriesgado. En algunos casos similares que se me ocurrieron (donde no pudimos reproducir el defecto internamente), dejé en claro que si una solución quedaba en la naturaleza y no resolvía el problema del cliente, o tenía otras consecuencias negativas inesperadas, el tipo que proponía Tendría que ayudar al equipo de soporte para encontrar el problema real. Incluyendo tratar con el cliente si es necesario.

Me parece que necesitas un registro más detallado.

Aunque agregar más registros no puede garantizar que no necesite depurar (o, en este caso, reproducir la situación), le dará una mejor perspectiva de lo que realmente salió mal.

Especialmente en situaciones complicadas / de subprocesos, o cualquier cosa donde no pueda usar un depurador, recurrir a "debug by printf ()" podría ser su único recurso. En cuyo caso, registre todo lo que pueda (más de lo que espera) y tenga algunas buenas herramientas para filtrar el trigo de la paja.

  

¿Es razonable insistir en reproducir cada defecto y depurarlo antes de diagnosticarlo y solucionarlo?

Ya que nadie lo dijo en términos claros todavía: ¡Absolutamente no!

Como todo lo demás en el desarrollo de software, la corrección de errores significa tener en cuenta el tiempo, el riesgo y el costo. Encontrar un equilibrio entre estos es la mitad de la descripción del trabajo de un desarrollador.

Algunos errores no son lo suficientemente importantes para pasar 2 días, pero lo suficientemente importantes como para dedicar 10 minutos a solucionarlos. Otros errores no son deterministas y ya sabes que un entorno de prueba no puede probar que se hayan solucionado. Si la configuración del entorno de prueba tarda 2 días, no lo hace para estos errores. En su lugar, dedica tiempo a cosas más inteligentes, como encontrar formas de configurar un entorno de prueba en 5 minutos en lugar de 2 días.

Y, por supuesto, hay errores en los que si los entiendes mal, un cliente perderá $ 100'000 +. Y los errores en los que el cliente perderá más de $ 100'000 por cada hora, el error no se soluciona. Necesitas mirar el error y tomar una decisión. Las declaraciones generales para tratar todos los errores no funcionan igual.

Muy buena pregunta! Mi opinión es que si no puedes reproducir el problema, entonces no puedes decir el 100% con seguridad de que la solución que hiciste no:

a) realmente arregla el problema. b) crear otro error

Hay veces en que ocurre un error y lo soluciono y no me molesto en probarlo. Sé 100% seguro que funciona. Pero hasta que nuestro departamento de control de calidad diga que está funcionando, considero que todavía existe la posibilidad de que todavía haya un error presente ... o un nuevo error creado a partir de la solución.

Si no puedes reproducir el error y luego instalar la nueva versión y confirmar que está arreglado, no puedes, con un 100% de certeza, decir que el error se ha ido.

Intenté por unos minutos pensar en una analogía para ayudarte a explicar a los demás, pero nada me vino a la mente. Una vasectomía es un ejemplo divertido, pero no es la misma situación :-)

  

[error relacionado con] acceso simultáneo a la base de datos, implementación en clúster, multiproceso

     

¿Es razonable insistir en reproducir cada defecto y depurarlo antes de diagnosticarlo y solucionarlo?

No pasaría mucho tiempo tratando de reproducirlo. Parece un problema de sincronización y se encuentran más a menudo por razonamiento (a partir de registros como el que tiene para identificar el subsistema en el que se produce el problema) que por poder encontrar una forma de reproducirlo y atacarlo con un depurador . En mi experiencia, reducir el nivel de optimización del código o, a veces, e incluso activar la instrumentación adicional puede ser suficiente para agregar suficiente demora o la primitiva de sincronización que falta para evitar que el error se manifieste.

Sí, si no tiene una forma de reproducir el error, no podrá estar seguro de que lo ha solucionado. Pero si su cliente no le da la forma de reproducirlo, también puede estar buscando algo similar con la misma consecuencia pero una causa raíz diferente.

Ambas actividades (revisión de código y prueba) son necesarias, ninguna es suficiente.

Podrías pasar meses construyendo experimentos tratando de reprochar el error, y nunca llegar a ningún lado si no miraste el código y formaste una hipótesis para limitar el espacio de búsqueda. Podría pasar meses mirando a su ombligo intentando visualizar un error en el código, incluso podría pensar que lo ha encontrado una vez, dos veces, tres veces, solo para que el cliente cada vez más impaciente diga: "No, el error sigue ahí". "

Algunos desarrolladores son relativamente mejores en una actividad (revisión de código frente a pruebas de construcción) que la otra. Un administrador perfecto pesa estas fortalezas cuando asigna errores. Un enfoque de equipo puede ser aún más fructífero.

En última instancia, es posible que no haya suficiente información para corregir el error, y debe dejar que se marine durante un tiempo con la esperanza de que otro cliente encuentre un problema similar, lo que le dará más información sobre el problema de configuración. Si el cliente que vio el error realmente quiere arreglarlo, trabajarán con usted para recopilar más información. Si este problema solo surgió una vez, probablemente no sea un error de alta prioridad, incluso si el cliente es importante. A veces, no trabajar un error es más inteligente que soplar horas-hombre buscando un defecto muy oscuro sin suficiente información.