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?