我们的客户可以选择何时升级。因此，我的团队必须维护和支持我们软件产品的几十个版本。正如你所能想象的，这会导致大量的分支和合并，因为热修复程序和服务包必须在所有这些风格中传播。我对这种情况不满意。显而易见的解决方案就是不维护我们产品的这么多不同版本，但我无法获得这种明显的解决方案。因此，我正在探索降低团队维护工作的创造性选择。我正在考虑混合使用FeatureToggling和IoC来实现我们软件产品的n个版本。我的想法是，我可以为我的产品使用一个单一的代码库，并通过配置管理来管理行为和功能。这将代替必须在多个分支之间传播代码。这是一个合理的方法吗？还是我只是用一个问题换另一个问题？
这听起来很合理，因为这将是我在绿地环境中解决此类问题的方法。
不过，我们不要称之为功能切换。顾名思义，功能切换是一个开/关开关，这可能不是您所需要的。
有时，升级还涉及更改现有功能中的行为。这意味着你可能需要比开关更复杂的东西。
战略模式是一种更灵活的行为变化建模方式。每个策略都可以表示特定行为的特定版本，如果您根本不想要这种行为，则可以提供一个Null对象实现。换句话说，功能切换可以通过策略来实现。
您可以使用Dependency Injection将Strategies注入到应用程序内核中，并且可以通过配置系统配置Strategies的选择。我听说的大多数DI容器（在.NET和Java上）都支持基于文件的配置。
这基本上描述了外接程序体系结构。
现在，即使对于一个新手应用程序来说，这也不是一件容易的事。如果你有一个无头系统，这并不难，但一旦你有了UI，你就会开始意识到你也需要将UI架构组件化，这样你就可以通过Strategies插入UI元素。
至少可以说，在一个已有十年历史的代码库中，这将是我所说的"有趣的挑战"。