Uso de alternancia de funciones y IoC en lugar de código de ramificación: ¿buena o mala idea?

Question

Nuestros clientes pueden elegir cuándo actualizar. Por lo tanto, mi equipo, literalmente, tiene que mantener y admitir docenas de versiones de nuestro producto de software. Como se puede imaginar, esto genera una gran cantidad de ramificaciones y fusiones, ya que las correcciones urgentes y paquetes de servicios deben propagarse en todos estos sabores. No estoy contento con la situación. La solución obvia es simplemente no mantener tantas versiones diferentes de nuestro producto, pero esa solución obvia no está disponible para mí. Entonces, estoy explorando opciones creativas para reducir el trabajo de mantenimiento del equipo. Estoy considerando usar una combinación de Feature Toggling e IoC como una forma de implementar n-número de versiones de nuestro producto de software. La idea es que podría usar una única base de código para mi producto y gestionar comportamientos y características a través de la administración de la configuración. Esto sería en lugar de tener que propagar código a través de múltiples ramas. ¿Es este un enfoque razonable o estoy intercambiando un problema por otro?

Answer 1

Eso suena razonable, ya que esta sería la forma en que abordaría un problema de este tipo en un entorno completamente nuevo.

No lo llamemos Feature Toggle, though. Como su nombre lo indica, un Feature Toggle es un interruptor on/off, que puede no ser lo que necesita.

A veces, una actualización también implica cambió comportamiento en características existentes. Eso implica que probablemente va a necesitar algo más sofisticado que un interruptor on/off.

La Strategy pattern es una forma más flexible de modelar la variación en el comportamiento. Cada estrategia puede representar una versión particular de un comportamiento particular, y si no desea el comportamiento en absoluto, puede proporcionar una implementación de Null Object. En otras palabras, Feature Toggle se puede implementar con una estrategia.

Puede inyectar las Estrategias en su kernel de aplicación usando Inyección de Dependencia, y puede hacer la elección de Estrategias configurables a través de un sistema de configuración. La mayoría de los Contenedores DI de los que he oído hablar (en .NET y Java) admiten configuraciones basadas en archivos.

Esto describe esencialmente una complemento de arquitectura.

Ahora, incluso para una aplicación greenfield, esto no es tarea fácil de realizar. Si tiene un sistema sin cabeza, no es que es difícil, pero una vez que tiene la interfaz de usuario implicada, comienza a darse cuenta de que también va a necesitar un componente de la arquitectura de la interfaz de usuario para poder conectar los elementos de la interfaz de usuario a través de estrategias .

En una base de código de una década, esto sería lo que yo llamaría un "desafío interesante", por decir lo menos.