現在、製品の開発者向け API機能に取り組んでいます。
最初のバージョンがリリースされ、現時点では少数のユーザーしか使用していません。2 番目のバージョンの開発を開始して以来、API をよりエレガントで明確にするために、いくつかの部分が作り直され、いくつかの部分が削除されました。
ただし、2 番目のバージョンの展開は、古いバージョンのユーザーにとっては苦痛になる可能性があります。当社のマーケティング部門は、API 製品を大幅に強化し、機能を追加することを計画しています。
1)
新しい興味深い機能を追加するために「古いバージョン」に制約されないようにするには、どのようにシステムを構築すればよいでしょうか?変更された API
それとも、仕様に大幅な変更がないように、公開リリース前にかなり長い期間、サンドボックスで API 製品をテストする必要がありますか?
すでに一部のユーザーが使用している API に変更を加える必要がある場合、おそらく最善の方法は、古い API 呼び出しを非推奨にし、新しい呼び出しの使用を奨励することです。
古い API 呼び出しの機能を削除すると、おそらく古いコードの機能が損なわれるため、「古い」API を使用している一部の開発者は不満を抱くようになるでしょう。
特定の機能が非推奨であることを示す方法が言語で提供されている場合は、ユーザーが古い API 呼び出しの使用をやめ、代わりに新しい呼び出しに移行することを示すことができます。Java では、@deprecatedjavadoc タグを使用して、機能が非推奨になったことをドキュメントに記載できます。または、Java 5 以降では、@Deprecated注釈を使用して、非推奨の API 機能の呼び出しに対してコンパイル時の警告を発生させることができます。
また、古い API から新しい API への移行に関するヒントやヒントを提供して、人々が API とやり取りする新しい方法を使用することを奨励することもおそらく良い考えです。何をすべきか、何をすべきでないかについての例とサンプル コードがあれば、API のユーザーは新しい好ましい方法に従ってコードを書くことができます。
パブリック API を変更することは困難ですが、古いものから新しいものへの移行に注意を払うことで、API を使用するユーザーの負担をある程度軽減できると考えています。
Sun のAPI を廃止する方法と時期に関する記事を次に示します。この記事では、APIの一部を廃止するのが適切な時期について、さらに詳しい情報が提供される可能性があります。
Obsoleteまた、.NET の属性@Deprecatedは Java の注釈に似ていると付け加えた David Schmitt に感謝します。（残念ながら、この回答を同時に編集していたため、編集は私の編集によって上書きされました。）
これは、コミュニティとのバランスを取る必要があります。
古い関数を何年も保持すると、Win32 API (30000 のパブリック関数) になりますか?
API を常に書き直せば、新しいリビジョン (1.0、2.0、3.0、3.5...) が頻繁に出て、既存のプログラムが壊れたり、新しく改善された方法が導入されたりする .NET に似たものを得ることができます。 UIなど）
コミュニティが変化に寛容で、実験に寛容である場合、無駄のない最新の API を目指して努力し、何らかの破損、つまり多少の腐敗が生じることを理解するでしょう。一方、コミュニティに大量のレガシー コードがあり、最新バージョンに移行するリソースや希望がない場合は、下位互換性を維持する必要があります。そうしないと、それらのすべてが新しい API で機能しなくなります。
他の回答の 1 つに注意してください: API を非推奨にすることは、どの関数が「途中」であるかを示すためによく使用される方法ですが、それらが機能する限り、多くの開発者は新しいコードでもそれらを使用します。彼らは慣れています。「非推奨」の警告に実際に耳を傾ける意識と、古い API の他のインスタンスのコードを検索して更新する時間の両方を備えている、賢明な開発者はほとんどいません。
Microsoft は非常識な下位互換性で有名です。彼らが行ったことの 1 つは、古い廃止された呼び出しをすべて保持し、新しいプログラムが古い API では機能しなかった拡張機能にアクセスするために使用できる新しい呼び出しを追加することでした。
使用するプログラミング言語を指定しませんでしたが、.NET と Java の両方に、特定の API 呼び出しを古いものとしてマークするメカニズムがあります。下位互換性が非常に重要な場合は、同じルートを使用することをお勧めします。
下位互換性がデフォルトであるべきです。この原則を妥協すべき唯一の理由は、API がなんらかの理由で安全ではなく、ユーザーがより安全な方法に変更せざるを得ない場合です。
元の API に記述されたアプリケーションは、新しいバージョンでも引き続き動作することが理想的です。
新しい機能を追加すると同時に、古いアプリケーションを引き続き実行できるようにする 1 つの方法は、API 呼び出しの 2 つのバージョンを用意することです。
たとえば、現在、API で 2 つのパラメーター (引数) を取る関数Fooがあり、新しいバージョンでは実際には 3 つのパラメーターを取る必要があると判断したとします。Fooをそのままにして、3 つのパラメーターを取る新しい関数Foo2を追加します。
そうすれば、ユーザーは下位互換性のためにFooに対してコーディングを続けるか、新しい機能が必要な場合は新しいFoo2関数を使用できます。
この手法は、Microsoft で Windows API に一般的に使用されています。