11

お客様はいつアップグレードするかを選択できます。そのため、私のチームは文字通り、ソフトウェア製品の数十のバージョンを維持およびサポートする必要があります。ご想像のとおり、ホット フィックスとサービス パックをこれらすべてのフレーバーに伝播する必要があるため、多くの分岐とマージが発生します。私はこの状況に満足していません。明白な解決策は、単純に製品のバージョンをそれほど多く維持しないことですが、その明白な解決策は私には利用できません。そこで、チームのメンテナンス作業を軽減するためのクリエイティブなオプションを模索しています。ソフトウェア製品の n 個のバージョンを実装する方法として、機能の切り替えと IoC を組み合わせて使用​​することを検討しています。アイデアは、製品に単一のコード ベースを使用し、構成管理を介して動作と機能を管理できるというものです。これは、コードを複数のブランチに渡って伝播する必要がなくなるためです。これは合理的なアプローチですか、それともある問題を別の問題とトレードオフしているだけですか?

4

1 に答える 1

5

これは、グリーンフィールド環境でこのような問題に対処する方法であるという点で、合理的に聞こえます。

ただし、これをFeature Toggleとは呼びません。名前が示すように、Feature Toggleはオン/オフスイッチであり、必要なものではない場合があります。

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

戦略パターンは、動作のバリエーションをモデル化するためのより柔軟な方法です。各戦略は、特定の動作の特定のバージョンを表すことができます。動作がまったく必要ない場合は、Null オブジェクトの実装を提供できます。つまり、機能トグルは戦略で実装できます。

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

これは基本的にアドイン アーキテクチャを表します。

現在、未開発のアプリケーションであっても、これを実現するのは簡単なことではありません。ヘッドレス システムを使用している場合、それほど難しくはありませんが、UI が関与するようになると、UI アーキテクチャもコンポーネント化する必要があることに気付き始めます。これにより、ストラテジーを介して UI 要素をプラグインできるようになります。

10 年前のコード ベースでは、控えめに言っても、これは「興味深い課題」と言えます。

于 2016-02-01T11:46:46.490 に答える