¿Debo registrar un error que descubrí y parcheé?

Supongo que esta es una situación común: pruebo un código, descubro un error, lo soluciono y confirmo la corrección de errores en el repositorio. Suponiendo que muchas personas trabajan en este proyecto, primero debería crear un informe de error, asignarlo a mí mismo y referirme a él en el mensaje de confirmación (por ejemplo, "Solucionar el error #XYZ. El error se debió a X e Y. Lo solucionó por Q y R ")? Alternativamente, puedo omitir el informe de error y confirmar con un mensaje como "Se corrigió un error que causaba A cuando B. El error se debió a X e Y. Se corrigió por Q y R".

¿Qué se considera una mejor práctica?

Depende de quién sea la audiencia de un informe de error.

Si solo los desarrolladores lo miran internamente, para saber qué debe arreglarse, no se moleste. Es solo ruido en ese punto.

Lista no exhaustiva de razones para iniciar sesión de todos modos:

• Las notas de la versión incluyen información sobre errores corregidos (hasta cierto límite que cumple este error), especialmente si hay una vulnerabilidad expuesta por este error
• La gerencia quiere una noción de "Tiempo dedicado a la corrección de errores" / "Recuento de errores detectados", etc.
• Los clientes pueden ver el estado actual del rastreador de errores (para ver si se conoce su problema, etc.)
• Los probadores obtienen información sobre un cambio que deben probar.

Yo diría que depende de si su producto fue lanzado con el error o no.

Si se lanzó con el error que encontró, entonces sí, cree un informe de error. Los ciclos de lanzamiento a menudo pueden ser largos y no desea que su error se informe como un problema nuevo mientras ya lo haya solucionado.

Si su error aún no se ha enviado, entonces no seguiría el mismo camino. Ahora tendrá personas que intentan recrear su error, lo que no pueden porque todavía no está en una versión, esencialmente perdiendo su tiempo.

Debe hacer esto si se trata de un error que un cliente podría haber informado. Peor caso: arreglas el error, pero nadie lo sabe. El cliente informa el error. Su colega intenta corregir el error, pero no puede reproducirlo (porque ya lo solucionó). Es por eso que quieres un registro del error.

También es útil si realiza revisiones de código, donde generalmente el código se escribiría para alguna tarea y luego se revisaría. En ese caso, es mejor tener esa corrección de errores aislada, lo que puede requerir poner algo en su lista de tareas y luego hacer todo el trabajo.

Esto depende de varios factores.

Tanto Pieter B como Caleth enumeran algunos en sus respuestas:

• ¿El error ha sido parte de un lanzamiento oficial?
• ¿Se rastrea específicamente el número de errores / tiempo dedicado a ellos?

También puede haber procedimientos internos a seguir, a menudo respaldados por los requisitos de una certificación. Para ciertos certificados, es obligatorio que cada cambio en el código sea rastreable a un registro en un rastreador de problemas.

Además, a veces incluso las correcciones de errores de aspecto trivial no son tan triviales e inocentes como aparecen por primera vez. Si agrupa silenciosamente una corrección de errores de este tipo a la entrega de un problema no relacionado, y la corrección de errores luego resulta ser problemática, esto hará que sea mucho más difícil de rastrear, y mucho menos aislar o revertir.

Esta pregunta solo puede ser respondida realmente por el líder de su proyecto, o por quien esté a cargo del "proceso de emisión de boletos".

Pero déjame preguntarte de otra manera: ¿por qué no grabarías un error que parcheste?

La única razón insondable que veo es que el esfuerzo por presentar el informe de error, cometerlo y cerrarlo, es un orden de magnitud mayor que el tiempo para corregir el error.

En este caso, el problema no es que el error sea tan fácil de solucionar, sino que el papeleo lleva demasiado tiempo. Realmente no debería. Para mí, la sobrecarga para crear un boleto de Jira es presionar c, luego ingresar un breve resumen de 1 línea y presionar Enter. La descripción ni siquiera es general, ya que puedo cortar y pegar eso en el mensaje de confirmación, junto con el número de problema. Al final, . c <Enter>y el problema está cerrado. Eso se reduce a 5 pulsaciones de teclas sobre la cabeza.

No sé sobre usted, pero eso es lo suficientemente pequeño como para que sea una política incluso en proyectos pequeños para registrar cada corrección de errores de esta manera.

El beneficio es obvio: hay bastantes personas que pueden trabajar fácilmente con un sistema de tickets como Jira, pero no con el código fuente; También hay informes generados desde el sistema de tickets, pero no desde la fuente. Definitivamente desea que sus correcciones de errores estén allí, para aprender sobre posibles desarrollos, como una afluencia cada vez mayor de pequeñas correcciones de errores de 1 línea, que podrían proporcionarle una idea de los problemas del proceso o lo que sea. Por ejemplo, ¿por qué tiene que hacer tan pequeñas correcciones de errores a menudo (suponiendo que suceda a menudo)? ¿Puede ser que tus pruebas no sean lo suficientemente buenas? ¿La corrección del error fue un cambio de dominio o un error de código? Etc.

La regla que sigo es que si la sección en la que está trabajando nunca se ha lanzado y ni siquiera se ejecuta y ningún usuario la ha visto, repare cada pequeño error que vea rápidamente y continúe. Una vez que el software se ha lanzado y está en producción y algún usuario lo ha visto, cada error que ve recibe un informe de error y se revisa.

He descubierto que lo que creo que es un error es una característica para otra persona. Al corregir errores sin que esos errores sean revisados, podría estar creando un error en lugar de solucionarlo. Ponga en el informe de errores qué líneas cambiaría para corregir el error y su plan sobre cómo debería solucionarse.

En resumen: si este módulo nunca ha estado en producción, corrija cada error que vea rápidamente y siga las especificaciones. Si el módulo ya está en producción, informe cada error como un informe de error para revisar antes de corregirlo.

Sí .

Ya hay algunas respuestas que exponen situaciones en las que vale la pena crear un informe de error. Algunas respuestas Y difieren.

La única respuesta es que nadie lo sabe. Diferentes personas, en diferentes momentos , tendrán diferentes opiniones sobre el asunto.

Entonces, cuando encuentre un error, tiene dos soluciones:

• medite si vale la pena abrir un informe de error, o no, tal vez pida la opinión de un colega ... y luego, en algunos casos, lamente que no lo hizo porque alguien lo está preguntando y si ya tenía el informe, podría solo apúntales a eso
• solo crea el informe

Crear el informe es más rápido, y si no lo es ... automatícelo.

¿Cómo automatizarlo? Suponiendo que su rastreador admite secuencias de comandos, simplemente cree una secuencia de comandos a la que pueda llamar y que usará el mensaje de confirmación (título y cuerpo) para enviar un informe de error y cerrarlo como "implementado" inmediatamente, con la revisión de confirmación asociada para el seguimiento.

Estoy de acuerdo en que las otras respuestas ofrecen buenas reglas generales e incluso algunas tocan este punto, sin embargo, creo que aquí solo hay una respuesta segura.

Solo pregúntale a tu gerente . Bueno, su gerente o, alternativamente, el jefe de proyecto o maestro de scrum, etc., dependiendo de cómo esté estructurado su grupo.

Existen muchos sistemas diferentes de buenas y malas prácticas, pero la única forma de saber que está haciendo lo correcto para su equipo es preguntar.

Algo parecido a una conversación de corredor de un minuto haría: "Hola (jefe), si soluciono un error menor que solo toma unos minutos, ¿vale la pena hacer una multa o debería mencionarlo en mi mensaje de confirmación? " y lo sabrás con seguridad. Todas las buenas prácticas en el mundo son inútiles si ese método molesta a su equipo y a su gerente.