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

70

Trabajo para una empresa de productos de software. Tenemos grandes clientes empresariales que implementan nuestro producto y les brindamos apoyo. Por ejemplo, si hay un defecto, proporcionamos parches, etc. En otras palabras, es una configuración bastante típica.

Recientemente, se emitió un ticket y se me asignó una excepción encontrada por un cliente en un archivo de registro que tiene que ver con el acceso simultáneo a la base de datos en una implementación en clúster de nuestro producto. Por lo tanto, la configuración específica de este cliente puede ser crítica en la ocurrencia de este error. Todo lo que obtuvimos del cliente fue su archivo de registro.

El enfoque que propuse a mi equipo fue intentar reproducir el error en una configuración similar a la del cliente y obtener un registro comparable. Sin embargo, no están de acuerdo con mi enfoque y dicen que no necesito reproducir el error, ya que consume demasiado tiempo y requerirá la simulación de un clúster de servidores en máquinas virtuales. Mi equipo sugiere que simplemente "siga el código" para ver dónde está el código inseguro de subprocesos y / o transacciones y poner en marcha el cambio de un desarrollo local simple, que no es una implementación de clúster como el entorno en el que se produce el evento. del error se origina.

Para mí, trabajar con un plano abstracto (código de programa) en lugar de una manifestación tangible y visible (reproducción en tiempo de ejecución) parece difícil, así que quería hacer una pregunta general:

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

O:

Si soy un desarrollador senior, debería poder leer código de multiproceso y crear una imagen mental de lo que hace en todos los escenarios de casos de uso en lugar de requerir ejecutar la aplicación, probar diferentes escenarios de casos de uso en forma práctica, y paso a través del código línea por línea? ¿O soy un desarrollador pobre para exigir ese tipo de entorno de trabajo?

¿La depuración de mariquitas?

En mi opinión, cualquier solución enviada en respuesta a un ticket de incidente debe probarse en un entorno simulado para que esté lo más cerca posible del entorno original. ¿De qué otra manera puedes saber que realmente remediará el problema? Es como lanzar un nuevo modelo de vehículo sin pruebas de choque con un maniquí para demostrar que las bolsas de aire funcionan.

Por último, pero no menos importante, si estás de acuerdo conmigo:

¿Cómo debo hablar con mi equipo para convencerlos de que mi enfoque es razonable, conservador y más a prueba de balas?

    
pregunta amphibient 09.10.2013 - 19:03

17 respuestas

72
  

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

Debes dar tu mejor esfuerzo. Sé que a veces hay condiciones y entornos que son tan complejos que no se pueden reproducir exactamente , pero debes intentarlo si puedes.

Si nunca reprodujo el error y lo vio por sí mismo, ¿cómo puede estar 100% seguro de que realmente lo solucionó? Tal vez su solución propuesta introduce algún otro error sutil que no se manifestará a menos que intente para reproducir el defecto original.

  

Si soy un desarrollador senior, debería poder leer código (multiproceso) y crear una imagen mental de lo que hace en todos los escenarios de casos de uso en lugar de requerir ejecutar la aplicación, probar diferentes escenarios de casos de uso directamente. y paso por el código línea por línea? ¿O soy un desarrollador pobre para exigir ese tipo de entorno de trabajo? ¿La depuración de mariquitas?

No confiaría en alguien que ejecute el código "en su cabeza", si ese es su enfoque only . Es un buen lugar para comenzar . Reproduciendo el error, corrigiéndolo y luego demostrando que la solución evita que el error vuelva a ocurrir, ahí es donde debería terminar .

  

¿Cómo debo hablar con mi equipo para convencerlos de que mi enfoque es razonable, conservador y más a prueba de balas?

Porque si nunca reprodujeron el error, no pueden saber con seguridad si está arreglado. Y si el cliente regresa y se queja de que el error sigue ahí, eso no es ni una cosa buena. Después de todo, te están pagando grandes $$$ (supongo) para hacer frente a este problema.

Si falla para solucionar el problema correctamente, ha dejado de tener fe en el cliente (hasta cierto punto) y si hay competidores en su mercado, es posible que no sigan siendo su cliente.

    
respondido por el FrustratedWithFormsDesigner 09.10.2013 - 19:25
35

¿Cómo pretenden verificar que se solucionó el error en cuestión? ¿Quieren enviar un código no probado al usuario y dejar que lo descubran? No se puede confiar en que la configuración de prueba que nunca se mostró para reproducir el error muestre la ausencia del error. Ciertamente, no es necesario que reproduzca todo el entorno del cliente, pero sí lo suficiente para reproducir el error.

No creo que sea irrazonable intentar reproducir todos los errores antes de corregirlos. Sin embargo, si intenta reproducirlo y no puede, entonces se convierte en una decisión de negocios sobre si los parches ciegos son una buena idea.

    
respondido por el stonemetal 09.10.2013 - 19:22
27

Idealmente, quieres poder reproducir cada error para que, al menos, puedas probar que se ha solucionado.

Pero ... Eso no siempre es factible o incluso físicamente posible. Especialmente con el software de tipo "empresarial" donde cada instalación es única. También está la evaluación de costo / beneficio. Un par de horas de revisar el código y hacer algunas conjeturas acerca de un problema que no es crítico puede costar mucho menos que tener un equipo de soporte técnico pasar semanas tratando de configurar y duplicar el entorno de un cliente exactamente con la esperanza de poder duplicar el problema. Antes, cuando trabajaba en el mundo 'Enterprise', a menudo solo íbamos volando los programadores para que corrigieran errores en el sitio, porque no había manera de duplicar la configuración del cliente.

Entonces, duplique cuando pueda, pero si no puede, entonces aproveche su conocimiento del sistema e intente identificar al culpable en el código.

    
respondido por el GrandmasterB 09.10.2013 - 19:36
11

No creo que debas hacer que la reproducción del error sea un requisito para ver el error. Hay, como ha mencionado, varias formas de depurar el problema, y debería usarlas todas. ¡Debes considerarte afortunado de que hayan podido darte un archivo de registro! Si usted o alguien en su empresa puede reproducir el error, ¡genial! De lo contrario, aún debe intentar analizar los registros y encontrar las circunstancias en las que se produjo el error. Puede ser posible, como sugirieron sus colegas, leer el código, averiguar qué condiciones podría producir el error y luego intentar recrear el escenario usted mismo.

Sin embargo, no lance la revisión real sin probar. Cualquier cambio que realice debe pasar por el desarrollo estándar, las pruebas de control de calidad y la rutina de pruebas de integración. Puede resultar difícil de probar: usted mencionó el código de multiproceso, que es muy difícil de depurar. Aquí es donde estoy de acuerdo con su enfoque para crear una configuración o entorno de prueba. Si ha encontrado un problema en el código, le resultará mucho más sencillo crear el entorno, reproducir el problema y probar la solución.

Para mí, esto es menos un problema de depuración y más un problema de servicio al cliente. Has recibido un informe de error de un cliente; tiene la responsabilidad de hacer la diligencia debida para encontrar su problema y solucionarlo.

    
respondido por el Michael K 09.10.2013 - 19:22
9

En mi opinión ... como responsable de la toma de decisiones, debe poder justificar su posición. Si el objetivo del departamento de soporte de la tercera línea es solucionar los errores en el menor tiempo posible con el esfuerzo aceptable del cliente, cualquier enfoque debe cumplir con ese objetivo. Además, si se puede probar que el enfoque da los resultados esperados más rápidos, entonces no debería haber ningún problema para convencer al equipo.

Habiendo trabajado en el soporte, siempre he esperado razonablemente que el cliente pueda dar un "guión" de las acciones que realizaron para reproducir el error de forma consistente y, si no es así, los ejemplos candidatos que han producido el error.

Si era nuevo en el sistema y no tenía antecedentes con el código, mis primeros pasos serían intentar identificar las posibles fuentes del error. Puede ser que el registro sea insuficiente para identificar un código candidato. Dependiendo del cliente, podría inclinarme a darles una versión de depuración para que puedan devolverle los archivos de registro que brindan más pistas sobre la posición del código ofensivo.

Si soy capaz de identificar rápidamente el bloque de código, el mapeo visual del flujo puede ser suficiente para detectar el código. Si no, la simulación basada en la prueba unitaria puede ser suficiente. Es posible que la configuración del entorno de replicación de un cliente requiera menos tiempo, especialmente si existe una gran capacidad de replicación del problema.

Creo que puede encontrar que su enfoque debe ser una combinación de las soluciones propuestas y que saber cuándo renunciar a una y pasar a la siguiente es clave para hacer el trabajo de manera eficiente.

Estoy bastante seguro de que el equipo apoyará la idea de que si existe la posibilidad de que su solución encuentre el error más rápido, entonces dale un marco de tiempo adecuado para demostrar que no afectará demasiado el tiempo que se necesita para corregir el error cualquiera que sea la ruta que tome.

    
respondido por el stevemarvell 09.10.2013 - 19:31
8
  

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

Yo digo que sí, con algunas advertencias.

  • Creo que está bien leer el código e intentar encontrar lugares que parezcan problemáticos. Cree un parche y envíelo al cliente para ver si eso resuelve el problema. Si este enfoque sigue fallando, es posible que deba investigar otras opciones. Solo recuerde que si bien podría estar solucionando el error a , puede que no sea el error el que se informó.
  • Si no puede reproducirlo dentro de lo razonable y no puede encontrar ninguna bandera roja en el código, es posible que requiera una coordinación más estrecha con el cliente. He volado a los sitios de los clientes antes de hacer la depuración en el sitio. No es el mejor entorno de desarrollo, pero a veces si el problema es ambiental, entonces encontrar la causa exacta será más fácil cuando puedas reproducirlo de manera consistente.

He estado en el lado del cliente de la tabla en este escenario. Trabajaba en una oficina del gobierno de los EE. UU. Que usaba un clúster de base de datos Oracle increíblemente grande (varios terabytes de datos y procesaba millones de registros por día).

Nos encontramos con un problema extraño que nos fue muy fácil reproducir. Informamos el error a Oracle, y fuimos y vinimos con ellos durante semanas, enviándoles registros. Dijeron que no podían reproducir el problema, pero nos enviaron algunos parches que esperábamos que pudieran solucionar el problema. Ninguno de ellos lo hizo.

Finalmente, llevaron a un par de desarrolladores a nuestra ubicación para solucionar el problema en el sitio. Y fue entonces cuando se encontró la causa raíz del error y un parche posterior solucionó el problema correctamente.

    
respondido por el M. Scott Ford 09.10.2013 - 21:29
6

Si no está seguro acerca del problema, no puede estar seguro acerca de la solución. Saber cómo reproducir el problema de manera confiable en al menos una situación de caso de prueba le permite demostrar que sabe cómo causar el error y, por lo tanto, también le permite demostrar, por otro lado, que el problema se resolvió debido a la falta subsiguiente. de error en el mismo caso de prueba después de aplicar la corrección.

Dicho esto, las condiciones de carrera, los problemas de concurrencia y otros errores "no deterministas" están entre los más difíciles para que un desarrollador los identifique de esta manera, ya que ocurren con poca frecuencia, en un sistema con mayor carga y más complejidad que cualquiera Copia del programa del desarrollador, que desaparece cuando la tarea se vuelve a ejecutar en el mismo sistema más adelante.

Más a menudo que no, lo que originalmente parece un error aleatorio termina teniendo una causa determinista que hace que el error sea deterministicamente reproducible una vez que sepa cómo hacerlo. Los que desafían esto, los verdaderos Heisenbugs (errores aparentemente aleatorios que desaparecen al intentar probarlos en un entorno estéril y monitoreado), están relacionados con el tiempo del 99.9%, y una vez que entiendes eso, tu camino hacia adelante se vuelve más claro; busque cosas que podrían fallar si algo más tuviera una palabra al margen durante la ejecución del código, y cuando encuentre dicha vulnerabilidad, intente explotarla en una prueba para ver si presenta el comportamiento que está intentando reproducir.

En estas situaciones, generalmente se requiere una cantidad significativa de inspección de código en profundidad; tienes que mirar el código, abandonar cualquier noción preconcebida de cómo se debe comportar el código , e imaginar los escenarios en los que podría fallar en la forma en que tu cliente ha observado . Para cada escenario, intente desarrollar una prueba que pueda ejecutarse de manera eficiente dentro de su entorno de prueba automatizado actual (es decir, sin necesidad de una nueva pila de VM solo para esta prueba), que demostraría o refutaría que el código se comporta como esperaba ( lo cual, dependiendo de lo que esperaba, probaría o refutaría que este código es una posible causa de los problemas de los clientes). Este es el método científico para los ingenieros de software; observar, formular hipótesis, probar, reflexionar, repetir.

    
respondido por el KeithS 09.10.2013 - 21:32
4
  

¿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.

    
respondido por el reinierpost 10.10.2013 - 02:18
3

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"?

    
respondido por el KutuluMike 09.10.2013 - 22:58
3

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.

    
respondido por el Tulains Córdova 09.10.2013 - 19:29
3

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.

    
respondido por el RemcoGerlich 17.04.2015 - 10:31
1

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.

    
respondido por el kriss 10.10.2013 - 09:19
1

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.

    
respondido por el Mawg 17.04.2015 - 09:38
1
  

¿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.

    
respondido por el Peter 01.12.2015 - 17:41
0

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 :-)

    
respondido por el Jaydel Gluckie 09.10.2013 - 19:33
0
  

[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.

    
respondido por el AProgrammer 09.10.2013 - 21:34
0

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.

    
respondido por el SeattleCplusplus 23.03.2014 - 19:47

Lea otras preguntas en las etiquetas