分岐コードの代わりに機能トグリングとIoCを使用する - 良いか悪いのか？

Question

私たちのクライアントはいつアップグレードするかを選択します。だから、私のチームは文字通り、ソフトウェア製品の数十のバージョンを維持し、サポートしなければなりません。ホットフィックスとサービスパックがこれらのすべての味に広がっている必要があるので、多くのブランチングとマージの結果を想像することができます。私は状況に満足していない。わかりやすい解決策は、私たちの製品の多くの異なるバージョンを維持することではありませんが、明らかな解決策は私にはありません。だから、私はチームのメンテナンス作業を減らすための創造的な選択肢を模索しています。 n個のバージョンのソフトウェア製品を実装する方法として、Feature TogglingとIoCの組み合わせを使用することを検討しています。アイデアは、自分の製品に単一のコードベースを使用し、構成管理を通じてビヘイビアと機能を管理できるということです。これは、複数のブランチにコードを伝播させる必要がなくなります。これは合理的なアプローチですか、私はもう一つの問題を別のものと交換していますか？

Answer 1

これは、グリーンフィールド環境でこのような問題を解決する方法であるという点で、妥当と思われます。

機能トグルとしましょう。名前が示すように、Feature Toggleはオン/オフスイッチです。これは必要でない可能性があります。

アップグレードには、が変更され、既存の機能での動作が変更されることがあります。これはおそらくオン/オフスイッチよりも洗練されたものが必要になることを意味します。

Strategy patternは、動作の変化をモデル化する、より柔軟な方法です。各戦略は特定の動作の特定のバージョンを表すことができます。動作をまったく必要としない場合は、Null Objectの実装を提供できます。つまり、機能トグルは戦略で実装できます。

依存性注入を使用してアプリケーションカーネルに戦略を注入することができ、構成システムを使用して構成可能な戦略を選択できます。私が聞いたほとんどのDIコンテナ（.NETとJava上）は、ファイルベースの設定をサポートしています。

これは、基本的にアドインアーキテクチャを記述しています。

今では、緑地のアプリケーションであっても、これは簡単に行えません。ヘッドレスシステムの場合はであり、それはではありませんが、一度UIを組み込むと、UIアーキテクチャーもコンポーネント化する必要があることに気付き始めます。これにより、戦略を介してUI要素をプラグインできるようになります。

10年前のコードベースでは、これは私が「面白い挑戦」と呼んでいたものです。