¿Un cheque grande o varios más pequeños?

Ayer, cuando revisé la última versión de nuestra herramienta interna, vi más de 30 nuevas versiones. Esto me dio curiosidad ya que pensé que alguien finalmente solucionó esos molestos errores y agregó esa característica que estaba esperando tanto time … ¿y adivinen qué? Nada de esto sucedió, alguien simplemente pensó que sería bueno actualizar algunos encabezados y hacer un ajuste menor de dos o tres funciones. Todo en un compromiso separado. Estupendo.

Esto generó una discusión en nuestro equipo: ¿se debería considerar que está bien o deberíamos prohibir ese "abuso"? Podría decirse que esto realmente podría caber en uno o dos commits, pero 30 parece mucho. ¿Cómo debe manejarse esto? ¿Cuál es la mejor práctica?

Deberías comprometerte cada vez que realices un cambio y estés a punto de pasar al siguiente.

No debe comprometer nada que impida la construcción del proyecto.

Debería completar el post de compromiso para que la gente sepa qué cambios se han realizado.

Eso me va a hacer … No creo que se haya hecho algo a less que lo vea en el post de compromiso …

En general, creo que una confirmación debe estar relacionada con una tarea lógica, por ejemplo, corregir el error # 103 o agregar una nueva function de printing. Esto podría ser un file o varios, de esa manera puede ver todos los cambios realizados para una tarea en particular. También es más fácil deshacer el cambio si es necesario.

Si cada file se marca uno por uno, no es fácil ver los cambios realizados para una actualización / tarea en particular.

Además, si se completan múltiples tareas en una confirmación, no es fácil ver qué cambios pertenecen a cada tarea.

No me importaría la cantidad de confirmaciones, ya que cada confirmación mantiene la consistencia del proyecto (la creación aún tendrá éxito). Este es un recuento interno que no debería molestarlo. Si quiere cambiar algo aquí, mejor dígale a la gente que use algunos posts de confirmación estructurados (como "[corrección de errores] …", "[function] …", "[corrección menor]").

Por cierto, si quiere saber si se han solucionado los errores o si se han agregado características, usar un sistema de localización de fallos es mucho mejor que comprobar las confirmaciones en una herramienta similar a SVN.

La batalla contra la entropía del código es un esfuerzo de equipo continuo. Los loggings menores donde uno solo 'arregla las windows rotas' a lo largo de un path deben ser alentados, no desaprobados. El repository fuente es la herramienta incorrecta para realizar un seguimiento de las correcciones de errores, para eso es un rastreador de errores, así que la inconveniencia de localizar arreglos al escanear el repository de código y no el repository de fallos me parece totalmente despreciable.

Trabajo en un equipo de tamaño moderado en una gran base de código (~ 1M LOC) con una gran historia (~ 20Y). Gran parte del código es un montón de desorder: lógica de twig podrida, API obsoleta, convenciones de nomenclatura, incluso indentación aleatoria a menudo hace que leer sea un misterio. Inicié un hábito de mejoras de legibilidad menores "drive-by", para tratar de luchar contra la podnetworkingumbre total del código, y estoy tratando de conseguir que los compañeros de equipo adopten el mismo hábito.

A less que tus circunstancias sean radicalmente diferentes, trataré de pensar favorablemente sobre cualquier iniciativa de este tipo. La alternativa (con la que estoy muy familiarizado) es el estancamiento temeroso, que condena a cualquier código a pudrirse.

    Intereting Posts