11

私は、GUI (グラフィカル) と API (スクリプト) インターフェースの両方を持つアプリケーションに取り組んでいます。当社の製品には非常に大きなインストール ベースがあります。多くのお客様が、当社の製品を使用するスクリプトの作成に多くの時間と労力を費やしてきました。

すべての設計と実装において、(当然のことながら) 100% の後方互換性を維持するという非常に厳しい要件があります。以前に実行されたスクリプトは、新しいソフトウェア バージョンが導入されたときに、変更を加えずにまったく同じ方法で実行し続ける必要があります。

残念なことに、この要件は私たちの手を後ろに縛り付けることがあります。なぜなら、私たちのイノベーション能力や物事を行う新しいより良い方法を考え出す能力が実際に制限されるからです。

たとえば、すでに可能になっているタスクを達成するためのより良い (そしてより使いやすい) 方法を思い付くかもしれません。このより良い方法をデフォルトの方法にすることが望ましいですが、下位互換性に影響する可能性があるため、これを行うことはできません。そのため、ユーザーが利用可能になる前にユーザーが「オン」にする必要があるという新しい (より良い) 方法をモードとして残すことに固執しています。ドキュメンテーションやオンライン ヘルプを読まない限り (多くの顧客は読まない)、この新しい機能は永久に隠されたままである。

Windows Vista が最初に登場したとき、多くの人が Windows Vista で動作しなかったすべてのソフトウェアと周辺機器に悩まされたことを私は知っています。そのせいでかなり評判が悪かったです。しかし、Microsoft は、多くのユーザーの下位互換性を犠牲にして、Vista でいくつかの大きな革新を行うことに成功したこともわかります。彼らは危険を冒しました。それは報われましたか？彼らは正しい決断をしましたか？時間が経てば分かると思います。

イノベーションと下位互換性という相反するニーズのバランスをとっていますか? ジャグリング行為をどのように処理しますか？

4

4 に答える 4

5

私のプログラミング経験に関する限り、過去の受信データが正しく使用されるのを妨げる何かを根本的に変更する場合、新しいデータで使用するために変換できる古いデータの抽象化レイヤーを作成する必要があります。フォーマット。

基本的に、「改善された」方法をデフォルトとして設定し、コンバーターを介して古い形式のデータを読み取れるようにしますが、データを新しい形式として保存または保存します。

ここで重要なことは、テスト、テスト、テストだと思います。後方互換性は、前方への進行を妨げるべきではありません。

それはちょうど私の2cです

于 2008-10-02T05:37:21.337 に答える
1

開発を 2 つのブランチに分割します。1 つは後方互換性を維持するブランチで、もう 1 つは新しいメジャー リリース用であり、後方互換性が失われつつあることを明確にします。

于 2008-10-02T06:01:19.670 に答える
1

あなたが尋ねなければならない重要な質問は、顧客がそうではないかもしれないと認識していても、顧客がこの「改善」を望んでいる/必要としているかどうかです. 物事を行う特定の方法が確立されると、ワークフローの変更は非常に「費用のかかる」操作になります。ユーザーのコンピューターの知識によっては、UI の変更に適応するのに時間がかかる場合があります。

クライアントと取引している場合、イノベーションのためのイノベーションは必ずしも楽しいものではありませんが、これらの改善を開発することは楽しいことです。

于 2008-10-02T09:45:28.697 に答える
0

下位互換性を維持するための革新的な方法を常に探すことができます。

于 2008-12-05T22:09:42.877 に答える