si siempre ingresa un error en un sistema de seguimiento de errores [duplicado]

7

Para un proyecto que haré en la escuela pronto trabajaré con otras 6 personas. Probablemente usaremos YouTrack para rastrear nuestros errores y, obviamente, podemos ver el valor en este sistema.

Sin embargo, mi pregunta es si siempre se debe ingresar un error en el sistema de seguimiento de errores. En nuestro caso, algunas personas serán desarrolladores front-end, otras serán desarrolladores back-end, pero la complejidad del proyecto no será de un nivel tan alto que los desarrolladores back-end no sabrían cómo resolver un error de front-end. . Con esto no quiero decir que realmente lo resuelvan, sino porque (piensan) que saben que es una solución fácil, lo que les impide simplemente dejarle saber a uno de los desarrolladores front-end sobre el error al decirle al otro lado de la mesa.

Las principales razones que se me ocurren son las siguientes:

  • Al principio, el error puede parecer muy fácil de solucionar, pero en realidad descubre un problema mucho más grande (en este momento, presumiblemente, se ingresaría, pero lo hizo el desarrollador de la fronda).
  • Puede sacar a alguien de la "zona" simplemente mencionando casualmente que tiene un error en algún lugar, que se puede resolver en 10 segundos, pero luego se requieren 15 minutos para volver a la zona.

Por otra parte, parece una tontería que tengas que introducir un error que podría arreglarse en 2 minutos, especialmente si la parte en la que estás trabajando en ese momento necesita ese error. para ser arreglado.

Entiendo que esto es probablemente un poco subjetivo, pero también creo que otras personas podrían dar muy buenas razones para hacerlo de una manera u otra, que es lo que me gustaría escuchar.

    
pregunta Mekswoll 11.01.2013 - 00:24

5 respuestas

17

Más importante que presentar un informe de error es crear un caso de prueba que lo active.

Si solo toma dos minutos arreglar un error, ¿qué tan rápido lo olvidaría?

Crea esa prueba, corrige el error y no volverá a subir su cabeza fea.

El caso de prueba es un informe de errores vivientes, en el sentido de que nadie tiene que navegar a través de una base de datos de errores para evaluar lo que podría necesitar atención.

Vea también esta inspiradora charla sobre rayos de Jon Arild Torresdal: Por qué no deberías rastrear errores

Tanto @Karl como @Andrew mencionan una importante advertencia: después de que se publique el código, cualquier error que no se corrija (fácilmente) ahora es parte del producto , y debería documentarse .

    
respondido por el Henk Langeveld 11.01.2013 - 03:31
11

En la escuela, supongo que no importa mucho ...

Pero en el gran mundo, sin embargo, sin duda debes registrar el error. Hay varias razones para esto.

  1. Una vez que se haya publicado el código, los cambios solo se deben realizar por motivos que se puedan rastrear. Esto es especialmente apropiado en industrias reguladas (aeroespacial, médica, etc.) donde la aprobación de tipo incluye auditorías de software.
  2. Significa que el cambio de código se puede rastrear a lo largo de todo el ciclo de vida, en particular la documentación de las pruebas y las versiones. por ejemplo, en un proyecto también deseará ampliar la especificación de la prueba
  3. Puede que en realidad no sea un error: es posible que hayas entendido mal o que sea lo que el cliente quiere
  4. Se asegura de que solo una persona intente solucionar el error
  5. Asegura la visibilidad de la administración: cuando se le pregunta por qué no ha terminado lo que DEBE haber estado haciendo, puede mostrar lo que HABÍA haciendo
  6. Hacerlo correctamente reduce el riesgo de agregar accidentalmente un error diferente (¿más grande?)
  7. Existe la posibilidad de que la causa del error original lleve a los desarrolladores a aprender lecciones
  8. etc
respondido por el Andrew 11.01.2013 - 07:24
6

Durante los últimos 10 años o más, siempre uso informes de errores en casos como usted describe.

Lo que vale la pena tener en cuenta es que con suficiente práctica, esto le llevará muy poco tiempo y esfuerzo (eso es una cuestión de fluidez ).

Otra cosa importante a considerar es que usar el seguimiento de errores debería ser conveniente . El propósito del sistema de seguimiento de errores es hacer que el desarrollador sea más productivo, no menos. Si es más fácil lograr el mismo objetivo sin la herramienta de seguimiento de errores que con él, este tipo de basura es el propósito de la herramienta.

  • Para ser precisos, puede ser algo incómodo al principio, cuando te estás acostumbrando a la herramienta, pero si después de una práctica considerable, todavía no lo hace. No se siente fácil, esto indica que hay algo mal, ya sea con la herramienta o con la forma en que la usa, o con la forma en que el proceso de seguimiento de errores se configura en su equipo.

Teniendo en cuenta lo importante que es la conveniencia, tenga en cuenta que una cosa en el título de su pregunta se siente realmente resbaladiza: "siempre ingrese un error" .

Esto parece suponer que siempre se debe crear un nuevo informe de error: un error típico de un novato; Yo mismo cometí este error, me causó bastante dolor y me tomó un tiempo entender que esto no es necesariamente así.

A veces podría ser más conveniente simplemente agregar el error que descubrió a algún informe existente o, si encontró varios errores, enumérelos en un solo informe.

  • En uno de los proyectos anteriores me asignaron para solucionar problemas descubiertos en la revisión de código realizada contra un componente en particular. El documento de revisión enumeró alrededor de 180 (ciento ochenta) artículos; Claro que iba a usar el rastreador de errores porque sabía que de otra forma sería una pesadilla seguir el progreso del trabajo.

    Pero tampoco iba a crear 180 informes de errores separados (¿por qué lo haría?), Acabo de crear uno para toda la lista bug report #123 address code review comments submitted 20.10.2010 against component XYZ .

    En el curso de mi trabajo, algunos de los artículos resultaron ser dignos informes de errores dedicados; No hay problema, creé esto cuando era necesario. La "tabla de progreso" en bug #123 se observó de la siguiente manera

    review item  status
    -------------------
    item 1       fixed
    ...
    item 11      not started
    ...
    item 21      in progress
    ...
    item 31      extracted to bug report id #234
    ...
    
  

parece tonto que tengas que introducir un error que podría solucionarse en 2 minutos

Silliness aquí depende de cuánto tiempo le lleve registrar el error que descubrió.

  • Si hace falta decir, media hora, definitivamente es tonto. Si toma de 5 a 10 minutos, no es demasiado inteligente, pero puede estar bien si ocurre con poca frecuencia. Finalmente, si toma menos de un minuto , ¿por qué no? No veo nada tonto aquí.

En realidad, en casos como ese, solo me lleva menos de un minuto , y he aquí por qué. Mira, esto es lo que tienes

  

la parte en la que estás trabajando en ese momento necesita que se corrija ese error

En cuanto a mí, la parte en la que estoy trabajando siempre se registra en el rastreador de problemas. Cuando encuentro un error de 2 minutos que necesita ser arreglado para esa parte , simplemente agrego un comentario en el informe de error en el que estoy trabajando, como

discovered and fixed <this bug>

Heck, hago esto incluso si la solución no es necesaria en este momento. ¿Por qué no?

    
respondido por el gnat 11.01.2013 - 08:53
2

Generalmente, no necesita un informe de error a menos que exista una versión del software con el error fuera de su equipo de desarrollo. Si no necesita uno, es posible que aún lo desee, si existe la posibilidad de que lo olvide antes de solucionarlo. Para mí, eso significa que si no lo he solucionado al final del día y no está en un archivo que actualmente haya revisado por otras razones.

    
respondido por el Karl Bielefeldt 11.01.2013 - 03:05
1

Un rastro de papel puede ser útil para cubrir tu trasero si las cosas se complican y la administración comienza a hacer preguntas. Un error oficial tendrá los detalles del error, el nombre de la persona que lo corrige, los nombres de las personas que lo revisaron y una forma de identificar los cambios reales en el código fuente.

Los gerentes aman los procesos, es una buena idea seguirlos.

    
respondido por el James 11.01.2013 - 00:30

Lea otras preguntas en las etiquetas