後方互換性と革新の相反するニーズをどのようにバランスさせますか？

Question

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

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

残念なことに、この要件により、手の後ろに手を縛られることがあります。これは、革新を行う能力を制限し、新しいより良い方法を思い付くためです。

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

Windows Vistaが最初に登場したとき、Windows XPで動作していても動作しなかったすべてのソフトウェアと周辺機器が原因で、Windows Vistaが多くの人を悩ませたことを知っています。このため、かなり悪い評価を受けました。しかし、多くのユーザーの後方互換性を犠牲にして、MicrosoftがVistaでいくつかの大きな革新を成し遂げたこともわかります。彼らは危険を冒しました。報われましたか？彼らは正しい決断をしましたか？時間だけがわかると思います。

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

Answer 1

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

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

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

2cだけです

Answer 2

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

Answer 3

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

クライアントがイノベーションのためにイノベーションを扱っている場合、これらの改善を開発するのが楽しいとは限りません。

Answer 4

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