Tengo dos aplicaciones, llamadas A y B. La versión actual de estas aplicaciones es 7.x (algunos clientes ejecutan 7.1, otros ejecutan 7.2, ...). Ambas aplicaciones usan un mismo marco común (llamemos a esto C), así:
+---+ +---+
| A | | B |
+---------+
| C |
+---------+
Debido a algunos nuevos clientes importantes, quiero tener la funcionalidad de A y B en una gran aplicación. No es posible fusionar A y B en una sola aplicación, por lo que ahora estoy tratando de integrar la funcionalidad de A en B. Hasta ahora todo bien, pero estoy empezando a encontrar algunos problemas.
En primer lugar, los clientes que solo usan la funcionalidad básica de B no están interesados en toda la nueva funcionalidad de A que se agrega (y que les causa una sobrecarga adicional). Solo quieren actualizar su versión B con soporte para nuevas versiones de Windows, ... y quizás también quieran toda la funcionalidad agradable que se agrega a C (el marco común) también.
En segundo lugar, los clientes que actualmente usan la aplicación A, no quieren pasar directamente a la aplicación B, aunque la funcionalidad combinada de A + B los ayudaría a largo plazo. Para actualizaciones fáciles, quieren seguir con A e incluso ver algunas mejoras en C.
Tercero, todos los desarrollos que estoy haciendo en B pueden tener un impacto en la capa común CEg para mejorar el rendimiento de un módulo en B, tengo que refactorizar un módulo en C, pero como C también se usa en A, Necesito hacer mucho más trabajo. Además, A es una aplicación más antigua y menos estructurada, y cada cambio en C podría hacer que A sea más inestable.
La pregunta es cómo proceder? Actualmente estoy pensando en dividir B en una versión 7.x (aún podría hacer algunos desarrollos menores aquí y la versión 7.3, 7.4 en los próximos años si es necesario), y una versión 8.x (que contendría todas las nuevas funcionalidades) . Para resolver el problema de la capa común, también podría dividir C en una antigua C (7.x) y una nueva C (8.x). Esto da el siguiente resultado:
+-------+ +-------+ +-------+
| A 7.x | | B 7.x | | B 8.x |
+-----------------+ +-------+
| C 7.x | | C 8.x |
+-----------------+ +-------+
La aplicación A ya no evolucionaría y se apegaría a la versión 7.x de la capa común C.
Dividir C significa que todos los desarrollos en C no se verán en los antiguos A y B (que todavía serían la versión 7.x), o si se deben hacer en la versión 7.x de A y B, requerirían hacer el desarrollos en ambos lanzamientos.
Una alternativa podría ser dividir B en B 7.xy B 8.x, pero esto limitaría las posibilidades de refactorización en C, y en realidad solo resuelve los dos primeros problemas.
¿Alguien tiene alguna experiencia con este tipo de cambio de lanzamiento importante? ¿Alguna otra idea?
fuente
Respuestas:
Por lo general, esto es solo un problema de interfaz de usuario: incorpore la funcionalidad de A en su aplicación combinada "B 8.x", pero sepárela de manera que los clientes de B no la vean en el nivel de UI. Cree un conmutador en la aplicación para que pueda activar la funcionalidad A solo para "clientes A". Probablemente necesite tener otro interruptor para ocultar la funcionalidad B para los clientes A (esto también le da la oportunidad de venderles la funcionalidad B como un módulo separado)
Supongo que esto no será un problema si te interesan dos cosas:
Finalmente, si puede migrar sus clientes A a B 8.x de esta manera, resolverá automáticamente su tercer problema.
Una cosa para agregar: estoy manteniendo una aplicación que estaba en una situación muy similar hace unos 15 años ("A 7.x" era un programa de MS DOS, "B 7.x" era un programa de Windows con muchas características nuevas , y "B 8.x" contenía todas las funciones de ambos predecesores, donde las antiguas funciones "A 7.x" se integraron en B y se vendieron como un módulo separado). No se sorprenderá cuando le diga que ya no tenemos clientes de MS DOS desde hace más de 10 años, por lo que la transición no fue un problema en absoluto.
fuente