inversion-of-control - 使用功能切换和 IoC 代替分支代码——好主意还是坏主意？

Question

我们的客户可以选择何时升级。因此，我的团队实际上必须维护和支持我们软件产品的几十个版本。正如您可以想象的那样，这会导致大量的分支和合并，因为热修复和服务包必须在所有这些风格中传播。我对这种情况不满意。显而易见的解决方案就是不维护我们产品的这么多不同版本，但我无法使用这种显而易见的解决方案。所以，我正在探索创造性的选择来降低团队的维护工作。我正在考虑使用功能切换和 IoC 的组合来实现我们软件产品的 n 个版本。我的想法是我可以为我的产品使用单个代码库，并通过配置管理来管理行为和功能。这将代替必须跨多个分支传播代码。这是一种合理的方法，还是我只是用一个问题换另一个问题？

Answer 1

这听起来很合理，因为这将是我在新建环境中解决此类问题的方式。

不过，我们不要称它为Feature Toggle。顾名思义，功能切换是一个开/关开关，可能不是您需要的。

有时，升级还涉及更改现有功能的行为。这意味着您可能需要比开/关开关更复杂的东西。

策略模式是一种更灵活的行为变化建模方式。每个策略都可以表示特定行为的特定版本，如果您根本不想要该行为，则可以提供Null Object实现。换句话说，Feature Toggle 可以通过 Strategy 来实现。

您可以使用依赖注入将策略注入您的应用程序内核，并且您可以通过配置系统对策略的选择进行配置。我听说过的大多数 DI 容器（在 .NET 和 Java 上）都支持基于文件的配置。

这实质上描述了一个插件架构。

现在，即使对于一个未开发的应用程序，这也不是一件容易的事。如果你有一个无头系统，这并不难，但是一旦你涉及到 UI，你就会开始意识到你也需要将 UI 架构组件化，这样你就可以通过 Strategies 插入 UI 元素。

在一个有十年历史的代码库上，至少可以说，这将是我所说的“有趣的挑战”。