Gerente de lectura de confirmaciones de control de versiones

Nuestro gerente está monitoreando los compromisos de Git en todos nuestros proyectos; Por lo general, esto no es un problema, y me encanta el hecho de que el control de versiones proporciona un registro de todo el trabajo que está sucediendo, especialmente para auditorías y análisis posteriores (en caso de que algo salga mal).

Sin embargo, el gerente ha hecho algunos comentarios preguntando en qué está trabajando la gente cuando ve una confirmación que lee "arreglos de estilo" o cualquier mensaje de confirmación que no hace referencia a un número de ticket en nuestro sistema de gestión de tareas.

¿Existe una solución social o técnica para esto?

Más información: este es un proyecto de mantenimiento, por lo que hay un montón de "tuvo que hacer A, luego B, luego C y luego D y luego finalmente implementé X".

Más información: el mensaje de confirmación particular que levantó una bandera con el gerente estuvo cerca de "incluía una mejor forma de X, Y y Z", que es más un mensaje de refactorización que una simple solución estilística.

version-control management

— Peter Mortensen
fuente

posible duplicado de ¿La referencia al error / problema en el mensaje de confirmación se considera una buena práctica?

— mosquito

Estoy de acuerdo con tu gerente. Mirar un registro de confirmación de dos años para descubrir cuándo algo cambió y ver confirmaciones como "arreglos de estilo" es muy molesto. Si su gerente no le permite agregar tareas de refactorización en el sistema de administración de tareas, ese es otro problema.

— Gort the Robot

La verdadera refactorización es aún más importante para capturar que los cambios estilísticos. Por lo menos el mensaje de registro debe decir lo que se está refactorizado, pero realmente me gustaría que se mide en la que todo el mundo sabía lo que estaba siendo rediseñado, QA sabía qué prueba más cuidadosamente, etc.

— Gort el Robot

^^^ lo que dijo @StevenBurnap: esta es una muy buena práctica. El solo hecho de poder referir la identificación del ticket en lugar de contaminar el mensaje de confirmación con largas explicaciones de qué tipo de mejoras de estilo / refactorización hay y por qué se desean, hace que valga la pena. Y no hay más que eso, el seguimiento de los esfuerzos, la comunicación con la gestión / control de calidad, etc, etc Y no me refiero a cómo es conveniente cuando se integra error de seguimiento con herramienta de revisión de VCS / código

— mosquito

Depende completamente de la situación. ¿El gerente está reaccionando ante un miembro del equipo que está gastando el 50% de su tiempo en refactorizar o en un solo compromiso sin referencia de ticket?

— winkbrace

Respuestas:

¿Existe una solución social o técnica para esto?

Supongo, pero esto no es un problema .

Su gerente debe saber lo que están haciendo. Deben asegurarse de que no está haciendo un montón de trabajo que no proporciona ningún valor, o por qué se priorizó el trabajo sin tickets. No hay daño en esto. En un mundo ideal, proporcionará beneficios, porque su gerente puede establecer expectativas con los negocios para que pueda hacer todo ese trabajo sin presión o interrupción.

Solo se convierte en un problema si su gerente piensa que solo se debe hacer el trabajo de tickets, y evita que el trabajo de limpieza técnica sea tickets. Siempre hay una deuda técnica que limpiar. Siempre hay que ajustar las cosas porque debería hacerlo, a pesar de que no proporcionan un beneficio comercial claro e inmediato.

— Telastyn
fuente

Si el arreglo estilístico es parte del ticket en el que está trabajando y está relacionado, entonces no hay nada de malo en registrarlo por separado con el mismo número de ticket en el que estaba trabajando para una mejor identificación.

Si solo está descubriendo cambios que deben hacerse y no están relacionados con el ticket en el que está trabajando actualmente, le sugiero que realice tickets relacionados con la deuda tecnológica y los ponga en su cartera de pedidos para volver a comentarlos más tarde.

Durante su planificación, puede pasar por los tickets relacionados con la deuda tecnológica y adjuntarlos a los tickets de mantenimiento reales en los que planea trabajar de esta manera para que sea más identificable.

Esto lo ayudará a eliminar esas soluciones "de la nada" y mantener todo encapsulado en la categoría de problemas / tickets específicos en los que está trabajando.

— AvetisG
fuente

Está bien, pero si es una solución trivial, entonces esto es completamente estúpido.

— Lightness compite con Monica el

La deuda tecnológica el 99.99% del tiempo no es un cambio trivial. Es por eso que digo hacer un boleto en lugar de sumergirse en otra cosa que es un gran cambio de contexto. Si es algo trivial y sin relación con lo que está trabajando, aún puede registrarlo bajo el nombre del ticket en el que está trabajando con un comentario por separado. O mejor aún, piense en una notación como QFIX para una identificación fácil más adelante, para que no tenga cambios triviales aleatorios flotando sin ninguna organización.

— AvetisG

¿Qué pasa si el gerente también está mirando a JIRA en busca de nuevos boletos y luego los cuestiona? no cuestiona cuándo se pasan los boletos de un sprint futuro al actual, pero tan pronto como alguien crea un nuevo boleto relacionado con la deuda técnica, se cuestiona.

— Rudolf Olah

La notación QFIX es algo que necesitaría hablar en equipo antes de implementar. Se trata de comunicación, no solo saltas y escribes tus propias reglas. Entonces, primero hablen de ello como un equipo, y luego, si no están de acuerdo con ellos, opten por la otra solución, que es verificarlo junto con su boleto principal en el que están trabajando con un comentario por separado. Sin embargo, tenga en cuenta, una vez más, solo si el cambio es trivial, lo que significa que no contiene ningún cambio lógico o grandes refactorizaciones. Cambios inocuos, inofensivos, triviales.

— AvetisG

@omouse Bien puede ser que su gerente esté microgestionando o que no esté lidiando adecuadamente con la deuda técnica. Sin embargo, el gerente es en última instancia responsable del proyecto en su conjunto, y responsable del código en sí mismo, por lo que idealmente debería ser consciente de algún nivel de todo el trabajo que se realiza y por qué.

— Gort the Robot

Esto también me molesta (sin juego de palabras :).

Los registros más útiles contienen comentarios que son únicos y específicos no solo de lo que cambió, sino de por qué. A veces termino poniendo comentarios de párrafo.

Ocasionalmente me meto en situaciones en las que un requisito de UI rebota una y otra vez una vez que el desarrollo ha comenzado, lo que me obliga a rebotar esencialmente el código también (sí, el mundo real a veces apesta). En estos casos, considero que es aún más importante que mis comentarios brinden claridad sobre por qué el rebote y, más importante, por qué el código termina donde lo hace. Luego, cuando la gerencia regresa después de hablar con los clientes y quiere saber por qué, puedo mostrarles sin tener que recordar la experiencia paso a paso.

— Worrystone
fuente