機能依存バージョンソフトウェアの構築

Question

私は、顧客が計算作業を行うために使用するプログラムを持っています。また、所要時間は、お客様が計算したいデータの量によって異なります。データが少ない顧客もいれば、多い顧客もいます（データが多いほどデータは小さくなりますが、データが大きいほど豊富になります）。そのソフトウェアのスケーラブルなバージョンを作成することは可能ですが、それはもちろん実装にコストがかかり、ソフトウェアの価格が上昇します。もちろん、マーケティングにはさまざまなオプションが必要です。たとえば、大量のデータがあり、支払いが可能な顧客の場合、スケーリングをサポートする、より拡張性の高いバージョンを提案します。他の人のために、彼らはより長い時間がかかるより安いバージョンを提案したいと思っています。

しかし、開発の観点からは、これらは同じ考えの2つの異なるバージョンのようなものです。したがって、何かが実装されている場合（新しいダイアログウィンドウなど）、両方のバージョンで実装する必要があります。もちろん、一部は再利用できますが、一部は特別な作業が必要になる場合があります（データアクセスの実装方法のため）。したがって、開発の観点からは、1つのバージョンの方がはるかに安価であるように見えます。 1つには無制限のスケーリングの可能性があり、もう1つにはそれがない2つのバージョンを構築することで、マーケティングの需要を満たすのは簡単です（そのための変数を持つことが可能であると仮定します）。しかし、彼らが本当にそれを必要としないという理由だけで、それが貧しい顧客に最悪のプログラムを与えるように感じるよりも。

この種のバージョンがどのように行われるか、そしてそれを行う理由は何ですか？デスクトップ用のウィンドウとサーバー用のウィンドウがあるように、デスクトップバージョンには接続できるユーザーの数などが制限されます。

qbd · Accepted Answer

さまざまな機能のオン/オフスイッチを備えたアプリケーションを1つだけ作成します。 1つのアプリケーションの開発と保守は、2つのアプリで同じことを行うよりもはるかに簡単です。 2つのアプリケーションは非常に似ているため、大きな問題にはならないと考えることができます。そのため、コードの再利用が多くなり、スイッチがないため、それぞれが単純になる2つのアプリケーションが得られます（多くの場合、複雑さが大幅に増します）。しかし、コードベースは最終的に分岐し（細心の注意を払わないと）、コードの再利用はますます困難になります。

そうは言っても、2つの別々のアプリの方が優れている場合があります。

スケーラビリティはパフォーマンスと同じではありません。よりスケーラブルなアプリケーションは、小さなデータセットの非スケーラブルなアプリケーションよりも遅くなる可能性があります（大幅にさえ）。
スケーラビリティやその他の機能により、アプリケーションの展開/管理が複雑になる場合があります。たとえば、スケーラブルなアプリケーションでは、簡単に拡張できる外部データベースが必要になる場合があります。個別に展開/管理する必要のない内部データベースだけで、スケーラブルではない場合があります。
多くの場合、機能が増えると、「スケーラブルな」ユーザーインターフェイスも増えます。これは、軽量アプリケーションの使用を複雑にする可能性があります。これは、追加機能がない場合にのみ、追加機能をサポートすることを目的としたインターフェイスがまだあるためです。
さまざまな機能のスイッチを使用すると、プロジェクトの複雑さが大幅に増します。基本的に、アプリケーションの2 ^（スイッチの数）バージョンをテストする必要があります。この複雑さは管理するには大きすぎる可能性があり、2つの別々のアプリケーションを使用する方が簡単な場合があります。ただし、これは非常に極端なケースです。

多くの場合、中途半端な方法を取ることができます-違いを抽象化する別のモジュールに違いを外部化します（基本的に戦略パターン）。たとえば、スケーラブルコアと非スケーラブルコアの両方が同じインターフェイスを持ち、自由に交換できるモジュールを使用できます。他の例としては、同じ処理コアで動作する異なるフロントエンド（ユーザーインターフェイス）を使用でき、各フロントエンドは異なるユースケース（ライトバージョンと機能ヘビーバージョン）に最適化されています。

Esben Skov Pedersen · Answer

同じものの2つのバージョンは絶対に避けなければなりません。代わりに、いくつかのウィンドウ/メニュー/機能を非表示にするように構成できるものを1つ作成します。代替案は非常に高価です。

2つのバージョンを作成するとします。両方のバージョンを作成し、テストを作成し、手動でテストする必要があります。両方のバージョンのバグ修正。両方のバージョンを維持する必要があります。

または、1つのバージョンをビルドします。次に、いくつかの機能をオフにするロジックを構築します。したがって、上記のリストと比較すると、機能をオフにするための小さなロジックの方が明らかに安価です。また、機能が実装されると、必要に応じて「ライト」バージョンで無料でオンにできるという利点もあります。

Fernando Cordeiro · Answer

特定のユースケースで、データセットに「制限」を実装し、データセットのサイズを顧客に請求してみませんか？ xレコードまたはxGbを超えた後、ソフトウェアがロックするか、アップグレードするまで、パフォーマンスなどに関する恐ろしいポップアップまたは警告が表示されます。

2つのバージョンで同じコードベースを維持するのは非常に簡単で、必要に応じて、より多くのバージョンに簡単に分割できます。

価格設定システムはまったく別の獣ですが、スケーラビリティを価格設定システムに最適に統合する方法については、単に非表示にするのではなく、価格設定システムにスケーラビリティを測定させることをお勧めします。

AvetisG · Answer

つまり、2つの選択肢があります。1つは両方のアルゴリズムを1つの場所に配置し、もう1つは別々のソフトウェア（ライトバージョン、プロバージョンなど）として使用することです。

最初のケースに関しては、スケーラブルな実装が含まれているため、おそらく多くの費用がかかるため、価格にあまり柔軟性がありません。

第二に、選択は、WordPressプラグイン/マーケティングソフトウェアの開発中に私が頻繁に使用したものです。

必然的にコードの重複と戦う方法は、共有ライブラリを作成することです。

例えば：

.NETでプロジェクトを実行していて、WPFフォームがまったく同じように見えると思われる場合は、それらを共有プロジェクトにカプセル化し、両方のバージョンでそれを参照するようにします。

JQueryを使用してプロジェクトを実行している場合は、2つのプロジェクト間で共有されているプラグインを使用してみてください。

他のプログラミング/スクリプト言語なども同様です。

このように、両方に属すると思われる機能を追加することにした場合は、共有プロジェクトにその機能が含まれます。それ以外の場合は、必要なバージョン用に特別に記述します。

そうすれば、いくつかの素晴らしい分離が得られ、途中でコードの重複と戦うことができます。