Responsabilidad de reproducir errores

Estoy desarrollando un programa usando una biblioteca hecha por otro programador (él trabaja en la misma compañía). Recientemente descubrí una fuga en la biblioteca, que ocurre bajo ciertas condiciones de red después de unas pocas horas de ejecución. Archivé un error con una descripción de las condiciones para que esta fuga ocurriera. Ese desarrollador respondió que "esto no es suficiente", "no es su responsabilidad reproducir errores" y tengo que crear una prueba unitaria para reproducir este error, de lo contrario no hace nada.

1. ¿Tiene razón?
2. ¿Qué puedo hacer en esta situación? Crear pruebas unitarias es imposible, porque depende de algunos tiempos de red aleatorios.

¿Tiene razón? Probablemente sea una pregunta que realmente no puede responderse sin conocer su empresa. Sin embargo, ciertamente no está siendo muy útil.

Levantaría el error con él (lo que ha hecho), si está causando un problema con su proyecto, lo plantearía como un bloqueador con su gerente de proyecto y dejaría muy en claro que ha solucionado el error con persona pero va a afectar su proyecto si no se soluciona de inmediato.

También iría y hablaría con el desarrollador y le explicaría por qué no es factible crear pruebas unitarias, pero estaría encantado de mostrárselo en su máquina (¿suponiendo que sea factible?).

Tiene 100% de razón en que debe proporcionar suficiente información para que el error sea reproducible; de ​​lo contrario, no hay posibilidad de averiguar si alguna solución que proporcione realmente funcionará.

Pero, en mi humilde opinión, está 100% equivocado porque esto debe ser en forma de una prueba unitaria. Si puede describir un escenario de prueba de una manera para que pueda reproducir la falla (al menos con una alta probabilidad en un período de tiempo razonable, o mediante una prueba manual), tiene una prueba de que el problema existe, lo que debería establecer a su colega en la responsabilidad de arreglarlo. Por supuesto, si puede crear un escenario que reproduzca el error más rápido, eso sería útil para él. Idealmente, uno haría una prueba automatizada de eso, y depende de su organización quién tiene la responsabilidad de esto.

Ambas partes deben poner un poco de esfuerzo.

El desarrollador de la biblioteca debe hacer un esfuerzo adicional incluso sin pruebas unitarias, porque algunos problemas no pueden reproducirse con las pruebas unitarias. A veces es hardware, a veces es una secuencia específica de acciones correctas del resto del programa que hace que la biblioteca produzca malos resultados.

Debería poner un esfuerzo adicional, porque después de todo esto no puede ser un error en la biblioteca, sino el resultado de acciones incorrectas del resto del programa (por ejemplo, el montón dañado puede hacer que cualquier biblioteca se comporte de manera extraña). Por lo tanto, tiene sentido reducir tanto como sea posible el código no relacionado con la biblioteca involucrado en la reproducción de errores. Y es probable que lo haga más rápido y limpio que una persona que no esté familiarizada con el código de su aplicación.

Si el autor de la biblioteca no puede reproducir el error en función de su informe, entonces no es razonable esperar que pase mucho tiempo en él, y mucho menos solucionarlo.

Pero también tiene una cantidad limitada de tiempo trabajando en un producto que es periférico para su interés. Desafortunadamente, esto puede significar que el error continúa existiendo y no se realiza ningún trabajo para resolverlo.

Afortunadamente, esto no es necesariamente un desastre, mientras que en un mundo ideal, todo el software estaría libre de errores, ese no es el caso, por lo que debemos priorizar en función de los problemas que nos causa.

Esto significa que, de hecho, es su responsabilidad desarrollar un caso de prueba reproducible SI LO QUIERE FIJAR. Puede que no le importe si se arregla, y en ese caso, ha hecho todo lo que puede y debe esperarse de usted. Es posible que desee solucionarlo, pero no lo suficiente como para dedicar tiempo para que sea reproducible en este momento. Eso es perfectamente aceptable.

Informar un error lo mejor que pueda en el tiempo que tiene que lidiar con él es simplemente buena ciudadanía, no necesita ir más allá de eso a menos que sea necesario para su programa. Y es posible que no quiera hacerlo, incluso entonces, puede haber otra biblioteca que podría usar, o puede ser posible crear la suya en un período de tiempo razonable. Básicamente, depende de usted decidir qué y qué tipo de esfuerzo vale para usted.

Me inclinaría a dejar que los perros dormidos mientan por ahora: usted ha planteado el problema y se le asigna a él. Presumiblemente, ¿existen procesos para rastrear errores pendientes y perseguirlos?

Si desea avanzar activamente en este proceso, le sugiero que hable con su gerente para ver si hay alguna herramienta de prueba disponible que pueda reproducir el problema de manera confiable.

Del lado del desarrollador: sería muy inerte de su parte no hacer nada dado que usted ha proporcionado la información requerida. Sin embargo, es posible que tengan una carga de trabajo masiva, por lo que no pueden dedicar el tiempo requerido para rastrear el problema.

Encontraste un error, lo reportaste y él está siendo un idiota al respecto.

Si ustedes dos hubieran sido amigos cercanos, habría hecho algo para ayudar, pero preferiría simplemente retrasar el problema.

Puede hacer más, informando más detalles e intentando respaldar sus afirmaciones de que está perdiendo memoria. Aún así, tiene sus propias responsabilidades y necesita terminar su propio trabajo.

Registre tanta información como pueda en el rastreador de errores y continúe.

Si vuelve a ver a esta persona en el futuro. Sea amigable, trate de hablar sobre intereses comunes y comprenda que las buenas relaciones son una forma mucho más efectiva de arreglar las cosas, que cualquier cantidad de datos que pueda proporcionar para respaldar un reclamo.

A menudo, lo que he encontrado en situaciones similares es la suposición de que todos los errores deben corregirse y, aunque es admirable, definitivamente es un gran objetivo (¡admitámoslo, nunca nos propusimos escribir errores!) En última instancia, no es realista. cualquier proyecto de un tamaño decente para corregir un error solo porque es un error (¡si puede encontrarlo!) Es por eso que tenemos metodologías, patrones y prácticas de gestión y codificación de proyectos, etc.

Entonces, una cosa que diría en defensa del propietario de la biblioteca (y ha sido el caso cuando he trabajado en algunos proyectos grandes) es que el tiempo de desarrollo cuesta dinero y es un recurso finito, por lo que la decisión de cómo se maneja un informe , quién investiga, qué pruebas se producen / necesitan y, en última instancia, si (y si es así, cuándo) se implementa una solución se basa únicamente en el impacto comercial. ¿Cuál es el impacto de reiniciar su proceso de ejecución prolongada de vez en cuando si falla y puede automatizarlo fácilmente (y tal vez no debería estar ya como una medida de programación defensiva?) ¿Es solo tiempo o hay más? ?

Mírelo también desde su punto de vista, un informe de error de un usuario de un problema impredecible en un código que ocurre muy raramente, solo junto con su código, posiblemente solo en una máquina y solo bajo un conjunto de tiempos inusuales las condiciones simplemente no tendrán una justificación sólida para una gran cantidad de tiempo de desarrollo para encontrar y solucionar, si es posible. Pero si es un caso de negocios lo suficientemente fuerte como para que ese usuario quiera / necesite tomarse el tiempo para investigar más a fondo y proporcionar un caso / aplicación de prueba confiable o una descripción del problema radicalmente más detallada que la inicial, entonces podría ser un juego completamente diferente .

Este es quizás un problema de comunicación que el propietario de la biblioteca no ha considerado ponerlo de esa manera y si tiene un caso comercial sólido (como su código es costoso para el negocio, tiene un requisito de cumplimiento legal, un agujero de seguridad o tiene algunos otro efecto importante), entonces es hora de patearlo a la gerencia y dejar que luchen.

Usted ha mencionado que "presenté un error con la descripción de las condiciones para que ocurriera esta filtración".

Si está seguro de que la descripción es realmente suficiente para reproducir el error, ya conoce las condiciones exactas. Ahora, si no puede escribir una prueba unitaria después de conocer las condiciones, eso claramente significa que no puede burlarse de algunos de los componentes involucrados o que algunas partes del código están demasiado estrechamente acopladas para permitir crear una prueba unitaria práctica.

Debe pedirle al propietario de la biblioteca que refactorice el código para permitirle crear una prueba unitaria. Tendrá que explicar claramente qué hay en la biblioteca que lo detiene para crear una prueba unitaria. Tendrá que refactorizar el código; de lo contrario, reconocerá que la prueba unitaria no es posible con el código actual. En ambos sentidos, tú ganas.

Si esto no funciona, las siguientes son las opciones que tiene:

• Puede reproducir errores con más evidencias.
• Intente involucrar a una autoridad superior y pídale que evalúe sus evidencias.
• Intente usar la biblioteca en la aplicación prototipo con un entorno simulado que se codificará solo para reproducir el error. De esa manera, podrá demostrar que existe al menos ese error.