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