¿Debo registrar arreglos triviales?

28

Estoy en una tienda de códigos de dos. Y aunque entiendo que un rastreador de errores es útil cuando el número de programadores es mayor o igual a uno, no estoy tan convencido de que valga la pena el registro de errores, cambios y correcciones cuando son triviales. Cuando encuentro un error simple, lo entiendo, lo soluciono y lo ejecuto a través de algunas pruebas. Y LUEGO me di cuenta de que tenía que ir a registrarlo.

Sé, en teoría, que el registro de errores se debe hacer en algún lugar entre encontrar el error y corregirlo, pero si arreglarlo es más rápido que registrarlo, parece una molestia. En las tiendas de códigos más grandes, el jefe presta atención a quién está haciendo qué y es bueno saber dónde se burlan los demás.

Me encuentro describiendo cosas que ya he arreglado y luego las cierro al instante. Tengo dudas de que alguien vuelva a ver este error cerrado nuevamente. ¿Es hora de recortar la grasa del proceso?

issue-tracking time-management process

— Philip
fuente

66

Cuando encuentre un error, anote cuál era el error en el papel. Cuando corrija el error, escriba qué archivos se modificaron. Antes de enviar la corrección, registre el error y luego envíe los cambios. Si hace esto cada vez que tenga un hábito, actualmente tiene un mal hábito, registrar errores no es una pérdida de tiempo.

— Ramhound

55

¿Cómo puede estar seguro de que estos errores son triviales?

2

@ashansky, ¿incluso leíste la segunda oración de mi pregunta?

— Philip

1

No registrar su propio trabajo es una forma segura de a) no obtener crédito por él yb) se le preguntará '¿por qué no se hace X y por qué está trabajando en Y?'

— Michael Durrant

1

No puedes registrar todo, simplemente no es práctico. ¿Por qué algunas personas saltan de un lado a otro y piensan que, de alguna manera, cómo no iniciar sesión algunas cosas menores EQUIVALE a no iniciar sesión en absoluto?

— Darknight

36

Debe registrar cada cambio que realice en su sistema. No hay nada de malo en registrarlo después del evento, siempre que enlace el informe de error al número de cambio.

Luego, si algo sale mal, puede rastrear el error y descubrir por qué realizó el cambio que realizó.

En la gran mayoría de los casos tiene razón y nadie volverá a verlos nunca más, pero en el 1 de cada 100 cuando algo sale mal, esta información será invaluable, especialmente si el problema solo aparece 6 meses después.

ACTUALIZAR

Obviamente, si todavía está desarrollando una nueva característica y descubre un error en parte de la característica que pensó que había terminado, no es necesario registrarlo como un cambio por separado. En estos casos, lo registraría en el elemento que solicita la función principal.

Una vez que el sistema con la función se ha pasado al control de calidad o al cliente, entonces es necesario hacer lo que describí anteriormente.

— ChrisF
fuente

Durante la fase de desarrollo inicial, antes de lanzar una primera versión del equipo de ingeniería, no es necesario registrar cambios en el rastreador de errores. Sin embargo, los cambios se anotarán en los registros de control de versiones de cada envío.

— uɐɪ

@Ian Esto es cierto, pero en general durante el desarrollo temprano (suponiendo que se refiere al desarrollo real y no a la creación de prototipos exploratorios o algo así), generalmente trabajará contra un conjunto de características de algún tipo. En ese caso, cada cambio debe vincularse con las características que admite. Las correcciones de errores menores en la línea a una característica "terminada" aún podrían vincularse contra ella para indicar el soporte de ese elemento. Eso sí, esto depende de cómo rastreas las características y especificaciones.

— CodexArcanum

1

@Darknight: ¡no es fácil! Nos ayuda el hecho de que usamos TFS y lo hemos configurado para no permitir registros que no tienen un elemento de trabajo asociado. Sí, puedes anular la regla, pero se detiene y te hace pensar en lo que estás haciendo.

— ChrisF

1

@Darknight Lo siento, pero esos números no significan nada. Decirlo no lo hace verdad; incluso si pudieras validar todo eso, ¿y qué? La única conclusión que puedo sacar de usted al presentar esos números es tratar de posicionarse de alguna manera por encima de los demás, lo que, francamente, parece inútil, innecesario y casi grosero / ofensivo.

— casperOne

3

@ Todos Tome esta discusión para chatear.

— maple_shaft

14

Si utiliza una herramienta de control de código fuente, puede describir el error que arregló en la descripción de confirmación y que suele ser documentación suficiente para la reparación de errores triviales y muy pequeños.

Además, si usa un rastreador de errores / características que está completamente integrado con su control de origen y repositorios, como FogBugz y Kiln , podrá usar la herramienta de búsqueda global para encontrar estas correcciones de errores y ver qué cambios de código realizó bastante fácilmente.

Además, puede asignar una revisión de código a su socio de programación para que pueda revisar la solución trivial que realizó, pero estoy divagando ...

— CFL_Jeff
fuente

1

Sí, yo hago eso. Aunque a veces me encuentro arreglando cosas mientras estoy en una rama y las agrupo en otras confirmaciones.

— Philip

1

Como referencia, aquí hay una lista combinada de rastreadores de problemas y control de fuente con los que se integran

— Matthieu

@matthieu Espera, ¿Jira se integra con SVN? Dios mío, ¿por qué no estamos haciendo eso? Parece que hay un par de complementos.

— Philip

5

Desde el punto de vista de las métricas, puede ser útil.

Esta información podría usarse para mostrarle al jefe varias cosas:

necesitamos más desarrolladores
Hay algo más en el proceso roto (¿por qué tantos errores? ¿El otro tipo genera la mayoría de los errores?), tal vez mostrando que tienes demasiados errores. Tal vez hay algo que causa esto? ¿Estás soltando demasiado temprano? ¿Se están realizando suficientes pruebas?
una buena lista de lo que ha estado trabajando en tiempo extra.

Dicho todo esto, depende de cuán pequeño sea un error del que estés hablando. Por ejemplo, uno de los revestimientos que puede detectar al agregar un nuevo código probablemente no tenga sentido.

— ozz
fuente

2

Intento registrar cada cambio que hago, independientemente del tamaño. Nunca se sabe cuándo usted, o alguien más (futuro o presente), tendrá que regresar y ver si ese cambio es la posible causa de otra cosa.

— Corv1nus
fuente

1

El seguimiento es importante, pero considere también otro escenario: cuando llegue el momento de su revisión. Sucederá formalmente en persona o de manera informal sin que usted esté allí a través de su jefe que obtiene informes del rastreador de errores.

Considérelos 'trucos' que terminen aumentando sus números. Después de todo, son errores que ha solucionado, y debería ser reconocido por corregirlos, incluso si son soluciones triviales.

Registrarlos

— Steven Evers
fuente

Sí, en las tiendas de códigos más grandes el jefe tiene "métricas" basadas en esto, por lo que es un buen consejo general. También conduce a personas que abusan del rastreador de errores y arrojan esas métricas al infierno sin sentido. Pero aquí solo somos yo y el otro tipo. El jefe no usa el rastreador de errores.

— Philip

1

Para responder esto realmente depende de dónde se encuentre en el proceso.

Estos pueden aplicarse a un nuevo proyecto o un nuevo conjunto de características que se está diseñando.

Diseño inicial Si encuentra errores en el código que creamos durante el diseño inicial, no sería necesario crear un seguimiento de errores para ello. Sugeriría una confirmación por separado para el cambio para que pueda desenrollarlo fácilmente si encuentra un problema más adelante.

Pruebas

Por lo general, el código todavía se consideró inmaduro durante las pruebas unitarias, por lo que a menos que lo haga un grupo diferente, diría que no. Si la prueba unitaria es realizada por un grupo diferente a un rastreador de errores, es una buena manera de formalizar el procedimiento de prueba.

La prueba CSCI depende. ¿Lo hace otro grupo? Si es así, sí (ver arriba). ¿Es este el último paso de la prueba antes del lanzamiento? Entonces sí, porque en este punto su software debe considerarse maduro. Si está interesado en las métricas, también sería bueno comenzar a rastrear errores en este punto.

Para cualquier nivel superior de prueba, debe usar el seguimiento de errores. En estos puntos, su software debe considerarse maduro y es importante rastrear errores.

Lanzamiento

Siempre debe rastrear errores en el código publicado. Esto es importante para la rendición de cuentas.

La racionalización de un proceso para satisfacer sus necesidades también es importante. ¿Realmente necesitas un gran sistema de seguimiento de errores? ¿Son todos los campos realmente tan importantes para un equipo de 2 personas?

— Charlie
fuente

1

¿Es posible que alguien más pueda encontrar el error, tal vez en una versión anterior del software que se ha lanzado al mundo exterior? Si es así, puede ser útil registrar tanto el error como la solución.

Otros han sugerido que si lleva más tiempo registrar el error que repararlo, entonces no vale la pena registrarlo. Sugiero que el período de tiempo relevante no está entre encontrar el error y solucionarlo, sino entre el momento en que se introdujo el error y el momento en que se lanzó la corrección.

Si el historial de cambios y versiones indica que el error nunca ha visto la luz del día, entonces el registro de la solución cuando lo verifica en el control de origen debería ser suficiente.

Esto está bastante cerca de esta pregunta , pero no estoy seguro de que sea un duplicado, ya que este se centra en soluciones triviales .

— Keith Thompson
fuente

1

Por qué no deberías rastrear los errores, por Jon Arid Torresdal , corrígelos en su lugar.

Durante el desarrollo: encuentra un error para una característica; se agrega un caso de prueba que rompe la acumulación , a continuación, comprueba en el partido ante la función.
Después del lanzamiento: documente el comportamiento . Si planea lanzar una actualización, vaya a 1. Si no está a cargo de esa versión, mantenga la prueba + corrección escondida en una rama privada.

Una vez que se publica el código, puede haber otras prioridades, y si bien la reparación del error puede ser trivial, la distribución de la solución puede no ser económica por sí sola, a menos que esté realizando una implementación continua.

— Henk Langeveld
fuente

-6

Depende de lo trivial que sea, uso esta medida:

Si se tarda más tiempo para registrar lo que tomó para fijar él, que no es digno de registro de la misma.

— Noche oscura
fuente

3

Solo porque lleva más tiempo iniciar sesión que repararlo no es suficiente justificación. ¡Decir ah! este tenía una explicación :)

— uɐɪ

2

No desestimé esto, pero si tuviera que adivinar por qué alguien lo hizo, es porque creen en registrar todas las correcciones de errores, o piensan que su respuesta no fue muy útil / perspicaz.

— CFL_Jeff

3

No voy a rechazarlo, pero no estoy de acuerdo con esto como una regla general (¡aunque en la mayoría de los casos puedo ver que tiene sentido!). ¿Qué pasa si tuvo un "error por un error" que se envió, pero se deslizó a través de la red de control de calidad? Se tarda más en entrar que a la solución ....

— PhillC

2

Si no está registrado, entonces no puede ser verificado como corregido por QA

— 17 de 26

3

-1 Esto es solo la arrogancia del programador (' No cometo errores') y la ignorancia (no he visto que suceda nada malo con correcciones menores). Un bloqueo realmente muy bueno y una grabación de una solución 'menor' generalmente ayuda con eso (también conocido como experiencia).

— Michael Durrant