Buscando la mejor manera de combinar la refactorización de la arquitectura profunda con el desarrollo basado en características

Planteamiento del problema:

Dado:

TFS como control de origen
Aplicación cliente de escritorio pesado con toneladas de código heredado con diseño de arquitectura malo o casi ausente.
Los clientes requieren constantemente nuevas funciones con calidad de sonido,
entrega rápida y se quejan constantemente de la interfaz de usuario poco amigable.

Problema:

La aplicación, sin duda, requiere una refactorización profunda. Este proceso inevitablemente hace que la aplicación sea inestable y se necesita una fase de estabilización dedicada.

Hemos intentado:

Refactorización en maestro con fusiones periódicas de maestro (MB) a rama de características (FB). (mi error) Resultado: muchas ramas inestables.

Lo que se nos aconseja:

Enlace al artículo (pdf)
Cree una rama adicional para la refactorización (RB) sincronizándola periódicamente con MB mediante la fusión de MB a RB. Después de estabilizar RB, sustituimos master con RB y creamos una nueva rama para una mayor refactorización. Este es el plan. Pero aquí espero el verdadero infierno de fusionar MB a RB después de fusionar cualquier FB a MB.

La principal ventaja: maestro estable la mayor parte del tiempo.

¿Hay mejores alternativas a los ingresos?

development-process refactoring

— Pavel Voronin
fuente

Posibles mejoras (en lugar de alternativas) a su proceso propuesto: la herramienta de combinación TFS es bastante difícil de manejar en comparación con varias utilidades de diferencias alternativas. Si aún no lo ha hecho, es posible que la fusión manual sea menos dolorosa si configura el cliente TFS para usar una utilidad diff más agradable, en lugar de la herramienta integrada. También puede encontrar útil la herramienta TFS Power Tools de Microsoft. Proporciona la capacidad de ejecutar una diferencia entre conjuntos de cambios o ramas, en lugar de solo entre archivos individuales.

— Brian

Tuve una situación similar en el pasado. Lo que hice:

evaluar el estado actual del proyecto; En la mayoría de las situaciones, la arquitectura (o la falta de ella) es el principal problema => repensarlo
generalmente hay características de trabajo, el problema es el alto acoplamiento entre las diversas partes del proyecto; Evalué cuáles son las características de trabajo y las reutilicé, pero en mi propia arquitectura
hablar con el cliente No sé lo que dice su gerente, pero creo que es importante hablar con el cliente y ser sincero; necesita saber que estás trabajando en la calidad de su producto. Hice un acuerdo para un plan de lanzamiento:
en la fase de fusión de las 2 soluciones (hacer que la arquitectura + reutilizar funciones del proyecto anterior) lo único que se lanzó (nuevas funciones) se hiciera en el producto anterior; sin embargo, las nuevas versiones contenían solo correcciones de errores importantes. Así que se hicieron muy pocos lanzamientos del producto anterior. Por lo tanto, las cosas cambiadas se fusionaron fácilmente en la nueva solución.
la primera versión nueva (versión del nuevo producto) contenía solo lo que contenía el producto anterior (sin características nuevas); después de estabilizarlo (la estabilización no tardó mucho) trabajé con un solo proyecto

Creo que no puede escapar de un período (razonablemente corto) de lanzamientos esporádicos. Es importante que pueda acordar esto con su cliente.

— Paul Ianas
fuente