Sospecho que me estoy centrando en el problema incorrecto, así que primero describiré cuál creo que es el problema antes de presentar la solución posiblemente subóptima que imagino.
Situación actual:
Actualmente, mis compañeros de trabajo comprometen sus cambios de código solo después de muuuucho tiempo en grandes partes con cambios que se extienden por todo el proyecto. Eso es progreso, supongo, porque no hace mucho tiempo solo pusieron archivos .zip en algún recurso compartido de red. Aún así, la fusión es una pesadilla, y, francamente, ya he tenido suficiente. Y también estoy cansado de hablar, explicar y rogar. Esto solo tiene que parar, sin que yo sea constantemente "el malo".
Mi solución:
dado que parece que no hay conciencia y / o interés en los problemas y no puedo esperar que ningún esfuerzo dure más que unos pocos días ... huelga que, horas, me gustaría que el servidor de subversión haga el persistente.
Mi pregunta:
¿Estoy fuera de lugar aquí o estoy buscando el problema incorrecto? Parece que me falta algo, y creo que estoy preguntando algo incorrecto al buscar herramientas para resolver mi problema.
¿Debería buscar una herramienta para resolver este problema o qué debo hacer para solucionarlo?
fuente
Respuestas:
Estás buscando una solución técnica a un problema humano. Eso rara vez funciona.
La razón de esto es porque si los miembros del equipo no aceptan algo (ni entienden las implicaciones), en lugar de seguir las reglas, intentarán eludirlas. Esa es exactamente la razón por la cual, por ejemplo, los desarrolladores deben aceptar y comprender las reglas de estilo en lugar de simplemente verse obligados a cumplir por un verificador.
Aquí hay algunos enfoques que utilicé en el pasado o que tengo en mente sin tener una oportunidad en la práctica. Algunos pueden no aplicarse a su caso, dependiendo de la posición que tenga en un equipo (si es un líder de equipo con excelente reputación, es probable que tenga una mejor oportunidad de hacer valer su punto de vista que si es un estudiante universitario que acaba de unirse a un equipo durante la duración de su pasantía).
Discuta el problema con sus compañeros de trabajo y explique las consecuencias de los grandes compromisos. Tal vez simplemente no entienden que las fusiones complicadas son una consecuencia directa de los commits raros, y que los pequeños y frecuentes commits harán que las fusiones (relativamente) sean fáciles.
Conocí a muchos programadores que simplemente estaban convencidos de que las fusiones siempre son complicadas. Hicieron como máximo una confirmación por día, evitaron el uso de herramientas poderosas como la diferenciación y fusión automática de Visual Studio, y tuvieron una mala práctica de fusión manual (a menos que "Tomar la mía" sin más inspección de diferencias sea realmente una buena práctica). Para ellos, esto no tenía nada que ver con ellos , y era la naturaleza inherente de una fusión.
Dé ejemplos concretos de lo que está sucediendo en otras compañías (especialmente aquellas por las que sus compañeros de trabajo tienen un profundo respeto) Puede que simplemente no se den cuenta de que se trata de un problema y estén convencidos de que un máximo de un compromiso por día es lo que hace cada equipo.
Algunas personas desconocen que hay equipos de 5 a 10 miembros que realizan hasta 50 impulsos a la producción, lo que se traduce en un promedio de 5 a 10 compromisos por día por persona. Es posible que no entiendan ni cómo es posible, ni por qué alguien lo haría.
Predicar con el ejemplo. Haz suficientes pequeños compromisos tú mismo. Si es posible, haga una breve presentación que muestre sus y sus fusiones una al lado de la otra durante una semana (no estoy seguro de si extraer este tipo de información es fácil desde un control de versiones). Haga hincapié en los eventuales errores que cometieron durante sus fusiones y compárelo con la cantidad de errores que cometió (que debería ser cercano a cero).
Use la técnica "Te dije", cuando sea apropiado . Cuando vea que sus colegas sufren una fusión dolorosa, comente en voz alta que los pequeños y frecuentes compromisos pueden hacer que las fusiones (relativamente) sean indoloras.
Explique que no hay una duración mínima para realizar una confirmación. Una confirmación puede incluso corresponder a un cambio menor realizado en unos segundos. Cambiar el nombre de un archivo, eliminar un comentario obsoleto, corregir un error tipográfico son tareas que pueden confirmarse de inmediato.
Los programadores no deberían temer hacer una pequeña confirmación, sino agregar muchos cambios en una gran confirmación.
Trabaje con individuos en lugar de un equipo, cuando sea apropiado. Si hay una persona que se niega particularmente a hacer pequeños compromisos frecuentes, hable con esta persona individualmente para ver por qué se niega.
Pueden dar razones perfectamente válidas que pueden darle una pista sobre lo que está sucediendo con un equipo. Algunas razones por las que me he escuchado:
"Mi maestro / mentor me dijo que la mejor práctica es hacer un compromiso por día". No me sorprende, dado lo que tenía que escuchar de mis maestros en la universidad .
"Mis colegas me dijeron que debería hacer menos compromisos". También me han dicho eso en algunos equipos, y entiendo su punto. Teníamos un registro que estaba prácticamente lleno de mis compromisos (no es difícil de hacer cuando cuatro compañeros de equipo ni siquiera hacen un compromiso por día), lo que frustraba a mis compañeros de trabajo.
"Pensé que los pequeños compromisos dificultan la búsqueda de una revisión". De alguna manera es válido, incluso cuando el equipo se esfuerza por escribir mensajes de registro descriptivos.
"No quiero desperdiciar demasiado espacio en nuestro servidor de control de versiones". La persona obviamente no comprende cómo se almacenan las confirmaciones (ni qué tan barato es el espacio de almacenamiento).
"Creo que un commit debería corresponder a una tarea específica". Dado que a menudo, una tarea corresponde a algún trabajo que se debe hacer en un día (como en los tableros de tareas de gestión visual), esto no es una coincidencia. Luego, la persona debe aprender a marcar la diferencia entre una tarea en un trabajo atrasado (de 2 a 8 horas de trabajo) y un cambio lógicamente aislado que debe comprometerse (unos segundos a unas pocas horas de trabajo). Esto también está relacionado con el punto 5.
Busque la razón por la cual el equipo no está haciendo compromisos más frecuentemente. Puede que te sorprendan los resultados.
Recientemente, mencioné en una respuesta diferente que la velocidad de una confirmación es importante, e incluso cientos de milisegundos pueden hacer que los desarrolladores se comprometan con menos frecuencia.
Otras razones pueden incluir:
Reglas demasiado complicadas para escribir un mensaje de confirmación.
La regla que obliga al desarrollador a vincular el commit a una tarea desde un sistema de seguimiento de errores.
El miedo a romper la construcción.
La falta de voluntad para lidiar con el riesgo de romper la construcción en este momento: si se compromete el viernes por la noche justo antes de partir, puede posponer el trato con la construcción rota hasta el lunes.
El miedo a hacer una fusión.
Determine si los desarrolladores entienden que hay otros beneficios para comprometerse con frecuencia . Por ejemplo, una plataforma de integración continua es un gran incentivo para tener compromisos frecuentes , ya que permite determinar con precisión dónde se introdujo la regresión .
Prefiero preferir que la plataforma CI me diga que rompí la compilación en la revisión 5023 que consiste en un cambio en dos métodos en un archivo que hice hace quince minutos, en lugar de en la revisión 5023 que consiste en cambios que abarcan cuatro docenas de archivos y representan 13 horas de trabajo.
fuente
Una organización que contraté en el pasado quería resolver este mismo problema, y se me ocurrió una solución social bastante buena: los desarrolladores no tienen sus propias computadoras. El equipo de desarrollo tiene computadoras, pero se le puede pedir a cualquier persona que trabaje en cualquier computadora de desarrollo en un día determinado. Por lo tanto, ¡registrarse es la única forma de asegurarse de que pueda seguir trabajando en lo que estaba haciendo ayer!
Luego, la gerencia dio la vuelta y revertió subrepticiamente los cambios en las computadoras después de horas para que todo lo que no se registrara se perdiera. Estas "fallas informáticas simuladas" solo tuvieron que ocurrir algunas veces antes de que los desarrolladores se subieran a bordo.
Por supuesto, es importante explicar el "por qué" de las reglas, así como el "qué". A menos que se aclare el "por qué", simplemente podrían almacenar su fuente en unidades USB o algo así.
fuente