¿Cómo refactorizar en una sucursal sin perder la cabeza?

Question

Refactorizo ​​mi código y el de otras personas. todo el tiempo.Cuando trabajo en una rama y no en Trunk, esto a veces resulta en fusiones extremadamente dolorosas, especialmente si no vuelvo a fusionarme con Trunk con regularidad (el código en la rama se aleja lentamente de Trunc, y cuando la gente modifica Trunk, yo tener que descubrir manualmente cómo aplicar esto a la sucursal).

Las soluciones que conozco son

1. Fusionarse constantemente hacia y desde Trunk: reduce las fusiones dolorosas, pero entonces ¿por qué trabajar en una sucursal?
2. Siempre que necesite refactorizar algo, cambie a Trunk, realice la refactorización allí y fusione con su rama. No lo encuentro muy práctico, ya que el costo real de cambiar de entorno para cada refactorización es enorme.

¿A qué te dedicas?

Answer 1

La refactorización a gran escala debe realizarse en el momento adecuado del cronograma de desarrollo.Si realiza grandes cantidades de refactorización cerca del lanzamiento, terminará lastimándose porque introducirá fusiones dolorosas en un momento en el que los cambios deben minimizarse.Cuanto más disruptiva sea su refactorización, más temprano debería ocurrir en el ciclo de desarrollo (y más proceso especial debería haber para ello, p. ej.detener las ediciones de los archivos afectados tanto como sea posible durante un período de tiempo).

Fusionarse constantemente hacia y desde el tronco es generalmente una buena práctica.

¿Por qué trabajar en una sucursal en ese caso?Porque tiene más control (puede dejar de fusionarse con el tronco para estabilizarlo para su lanzamiento, por ejemplo, sin detener los registros en su rama de desarrollo).Porque puede colocar un alto nivel de validación en torno a la fusión hacia/desde el tronco sin afectar mucho la velocidad de registro en la rama de desarrollo.

Answer 2

Elijo 1, hago pequeños cambios cuando es posible y reviso con frecuencia o, de lo contrario, las fusiones se vuelven dolorosas.Tener una rama separada puede facilitar las cosas si necesita trabajar en otras cosas al mismo tiempo o si la refactorización lleva más tiempo de lo que pensaba originalmente.La otra ventaja es que facilita que varias personas participen en la refactorización y puedes registrar cosas en la sucursal tantas veces como quieras.

Answer 3

Sugeriría la siguiente estrategia para escenarios en los que el intervalo de tiempo entre lanzamientos es de al menos 2 meses.

Cuando empiece a acercarse a un lanzamiento, cree una rama de lanzamiento.La rama de liberación debe tratarse como no hay refactorización aquí por favor y Estoy (casi) completo rama.Es en este punto que deberías empezar a centrar tu esfuerzo en estabilizar la liberación. en la rama de lanzamiento.Fusione cualquier corrección de defectos de la rama de liberación en el tronco según sea necesario.Mientras tanto, el maletero se trata como perpetuamente abierto para refactorización.Además, si es posible, intente reducir la refactorización a medida que se acerque a un lanzamiento importante y acelere la misma en los días inmediatamente posteriores.

En caso de que esté siguiendo una estrategia de lanzamiento continuo (es decir,una versión cada 1 o 2 semanas), no debe separar la refactorización y la codificación en ramas separadas, a menos que esté realizando una mejora quirúrgica importante.En tales situaciones de mejora quirúrgica (que deben espaciarse no menos de 3 meses cada una), elimine una versión de su programa con anticipación cada vez que desee realizar una combinación, use uno de los ciclos para la combinación de versiones y pruebas incrementadas, mantenga su dedos cruzados y luego soltar.

Answer 4

Los cambios deben ser rápido (para que no haya demasiados cambios debajo de usted) o de lo contrario local (por lo que solo le importan los cambios en una pequeña cantidad de lugares).

De lo contrario, la fusión puede suponer tanto trabajo como la refactorización.Como algoritmo, el bloqueo optimista simplemente no funciona cuando fallan demasiadas transacciones y deben reiniciarse.

Fundamentalmente, no se puede permitir una situación en la que 20 programadores de una empresa cambien los nombres del 50% de los métodos en el código base todos los días.Y de hecho, si varias personas siempre están refactorizando en los mismos lugares al mismo tiempo, entonces de todos modos solo están deshaciendo el trabajo de los demás.

Si los programadores dedican mucho tiempo a supervisar fusiones manualmente, presente a sus gerentes la oportunidad de aumentar la productividad cambiando la forma en que se definen y asignan las tareas.

Además, "refactorizar todo el sistema para utilizar fábricas en todas partes" no es una tarea."Refactorizar esta interfaz y sus implementaciones para utilizar fábricas" es una tarea.

Answer 5

Aquí es donde sobresale un buen VCS distribuido.Pero supongo que ya estás comprometido con SVN.

Personalmente, simplemente hago la refactorización y luego la fusiono lo antes posible para evitar el infierno del conflicto.No es el método más productivo, pero sí el menos propenso a errores.

Una vez tuve una sucursal que permaneció inactiva durante aproximadamente 3 semanas porque la función estaba "en espera" y era imposible fusionarla.Simplemente comencé la función nuevamente en una nueva rama, usando la anterior como referencia para ciertas partes.

Answer 6

A riesgo de ser obvio, diría que intente evitar las ramificaciones por completo.No se debe subestimar la cantidad de gastos generales que esto genera.Incluso cuando crea que no puede esperar más (lanzar uno del sistema en producción, lanzar dos que se están construyendo pero también cambiar las solicitudes para lanzar uno), intente encontrar otra manera:¿Realmente no hay manera de aislar la funcionalidad sin realizar ramificaciones (p. ej.¿Separar un proyecto "común" y algunos subproyectos)?¿Realmente no hay forma de integrar todo el código en el encabezado (p. ej.¿Crear clases de estrategia que incorporen las diferencias o crear interruptores para activar o desactivar nuevas funciones)?

Si es absolutamente necesario realizar una ramificación, elegiría la opción 1.Intente fusionar los cambios más pequeños posible y hágalo con frecuencia.

Answer 7

Comprométete temprano, comprométete con frecuencia.

O en este caso...Fusionarse temprano, fusionarse con frecuencia.

Answer 8

La integración continua es la clave...1 pequeño lote de cambios a la vez...