我们的客户可以选择何时升级。因此，我的团队实际上必须维护和支持我们软件产品的几十个版本。正如您可以想象的那样，这会导致大量的分支和合并，因为热修复和服务包必须在所有这些风格中传播。我对这种情况不满意。显而易见的解决方案就是不维护我们产品的这么多不同版本，但我无法使用这种显而易见的解决方案。所以，我正在探索创造性的选择来降低团队的维护工作。我正在考虑使用功能切换和 IoC 的组合来实现我们软件产品的 n 个版本。我的想法是我可以为我的产品使用单个代码库，并通过配置管理来管理行为和功能。这将代替必须跨多个分支传播代码。这是一种合理的方法，还是我只是用一个问题换另一个问题？
最佳答案
这听起来很合理，因为这将是我在新建环境中解决此类问题的方式。
不过，我们不要称它为功能切换。顾名思义，Feature Toggle是一个开/关开关，可能不是您需要的。
有时，升级还涉及更改现有功能的行为。这意味着您可能需要比开/关开关更复杂的东西。
Strategy pattern是一种更灵活的行为变化建模方法。每个策略都可以代表特定行为的特定版本，如果您根本不想要该行为，您可以提供 Null Object执行。换句话说，Feature Toggle 可以通过 Strategy 来实现。
您可以使用依赖注入(inject)将策略注入(inject)您的应用程序内核，并且您可以通过配置系统对策略的选择进行配置。我听说过的大多数 DI 容器(在 .NET 和 Java 上)都支持基于文件的配置。
这基本上描述了 插件架构 .
现在，即使对于一个未开发的应用程序，这也不是一件容易的事。如果你有一个 headless 系统，这并不难，但是一旦你涉及到 UI，你就会开始意识到你也需要将 UI 架构组件化，这样你就可以通过 Strategies 插入 UI 元素。
在一个有十年历史的代码库上，至少可以说，这将是我所说的“有趣的挑战”。
关于inversion-of-control - 使用功能切换和 IoC 代替分支代码——好主意还是坏主意？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9815600/