オープン ソースの Java ライブラリを C# に変換しています。C# には非推奨のタグが付けられた多数のメソッドとクラスがあります。このプロジェクトは白紙の状態から始める機会なので、それらを完全に削除する予定です。しかし、大規模なプロジェクトに取り組むのは初めてなので、このような状況が再び発生するのではないかと心配しています。アジャイル開発の多くは、何かをすぐに機能させ、必要に応じて後でリファクタリングすることを中心に展開するため、API の非推奨は一般的な問題に違いないように思われます。プロジェクトの将来の方向性が完全にわからない場合でも、API の非推奨を回避/最小限に抑えるために講じることができる予防策はありますか?
9 に答える
15
できることがたくさんあるかわかりません。要件が変更され、APIのクライアントが新しいAPIバージョンによって破損しないようにする必要がある場合は、非推奨のコードを誰も使用していないと思うまで、単に非推奨のコードに依存することになります。
コードに[Obsolete]属性を配置すると、廃止されたメソッドへの参照がある場合、コンパイラーは警告を作成します。このようにして、APIのクライアントは、コンパイラの警告を修正することに熱心であれば、新しいバージョンですべてを壊すことなく、徐々に新しいメソッドに移行できます。
文字列を受け取るObsoleteAttributeのオーバーライドを使用する場合に便利です。
[Obsolete("Foo is deprecated. Use Bar instead for munging widgets.")]
<軽薄>
おそらく、TimeBombAttributeを作成できます。
[TimeBomb(new DateTime(2010,1,1), "Foo will blow up! Better use Bar, or else."]
コードで、timebomb属性を持つメソッドを反映し、指定された日付以降に呼び出された場合はKaboomExceptionをスローします。これにより、2010年1月1日以降、廃止されたメソッドを使用しているユーザーがいないことを確認でき、APIを適切にクリーンアップできます。:)
</軽薄>
于 2009-07-06T14:31:40.357 に答える
5
マットが言うように、Obsolete属性はあなたの友達です...しかし、あなたがそれを適用するときはいつでも、呼び出しコードを変更する方法の詳細を提供してください。そうすれば、人々が実際に変わる可能性がはるかに高くなります。また、メソッドを削除する予定のバージョン（おそらく次のメジャーリリース）を指定することも検討してください。
もちろん、特にサンプルコードでは、廃止されたコードを呼び出さないように注意する必要があります。
于 2009-07-06T14:33:41.227 に答える
2
アジャイル開発の多くは、何かをすぐに機能させ、必要に応じて後でリファクタリングすることを中心に展開するため
それはアジャイルではありません。それは、アジャイルの名の下に偽装されたカウボーイ コーディングです。
理想は、あなたが持っている完了の定義によれば、あなたが完了したものは何でも完了しているということです。通常、国防総省は、「実装され、テストされ、関連するコードがリファクタリングされた機能」の行に沿って何かを述べています。もちろん、使い捨てのプロトタイプに取り組んでいる場合は、よりリラックスした DoD を使用できます。
API の変更は難しい獣です。変更するのがプロジェクト内部の API のみである場合、最善の方法は早期にリファクタリングすることです。内部 API を変更する必要がある場合は、すべての API クライアントを同時に変更してください。この方法では、リファクタリングの負債が非常に大きくならず、非推奨を使用する必要がありません。
公開された API については、少なくとも次のメジャー リリースかそこらまで、維持しなければならないソースとバイナリの互換性が保証されている可能性があります。互換性を維持しながら、古い API を非推奨としてマークすることは機能します。内部 API と同様に、非推奨の API を使用しないように、できるだけ早く内部コードを修正する必要があります。
于 2009-07-06T14:45:00.240 に答える
1
マットの答えは確かなアドバイスです。最初は、おそらく次のようなものを使用したいと思うでしょう。
[Obsolete("Please use ... instead ", false)]
コードを移植したら、false を true に変更すると、コンパイラはメソッドへのすべての呼び出しをエラーとして扱います。
于 2009-07-06T14:41:57.950 に答える
1
Josh Bloch の「優れた API を設計する方法とそれが重要である理由」をご覧ください。
最も重要な w/r/t 非推奨は、「疑わしい場合は除外する」ことを知っていることです。明確にするためにビデオを見てください。その API が再利用されることを現実的に期待している場合は、事実上決定を確定していることになります。
おそらく多くの異なる方法で再利用されることを期待しているため、API設計はアジャイルな方法で行うのがはるかに難しいと思います。自分に依存している他のチームを壊すことを心配する必要があるため、それは可能ですが、他のチームからの迅速な対応なしに適切な設計を実現するのは困難です。もちろん、ここでは非推奨が役に立ちますが、 API に関して言えば、 YAGNIの設計ヒューリスティックの方がはるかに優れていると思います。
于 2009-07-06T14:59:26.847 に答える
0
コードの非推奨は、継続的なリファクタリングや段階的な開発などのアジャイルプロセスの必然的な副産物だと思います。したがって、プロジェクトで作業しているときに非推奨のコードになってしまった場合、それは必ずしも悪いことではなく、単なる現実です。もちろん、コードを非推奨にするのではなく、多くのコードを保持し、それをさまざまなメソッドやクラスなどにリファクタリングすることになります。
つまり、結論：アジャイル開発中にコードが廃止されることを心配する必要はありません。それがしばらくの間その目的を果たしたのであれば、あなたは正しいことをしているのです。
于 2009-07-06T14:36:06.230 に答える
0
API 設計の経験則は、API がどのように機能するかではなく、何を行うかに焦点を当てることです。最終的な目標がわかったら、必要な絶対最小入力を見つけて、それを使用します。独自のオブジェクトをパラメーターとして渡すことは避け、データのみを渡します。
構成を実行から分離します。たとえば、画像エンコーダー/デコーダーがあるとします。
次のような呼び出しを行う代わりに:
Encoder.Encode( bytes, width, height, compression_type, compression_ratio, palette, etc etc);
成功する
Encoder.setCompressionType(compression_type);
Encoder.setCompressionType(compression_ratio);
etc,etc
Encoder.Encode(bytes, width, height);
そうすれば、設定を追加または削除しても、既存の実装が壊れる可能性がはるかに低くなります。
于 2009-07-06T15:46:21.420 に答える
0
普及するためのもう 1 つのアプローチは、クライアントを (Web) サービスに依存させることです。サービスをバージョン管理し、クライアントがルックアップを実行できるようにするコンストラクトがあります。これにより、より多くの可動部分と複雑さが方程式に追加されますが、多くのバージョンを引き継ぎ、本番環境で複数のバージョンをサポートする必要がある場合に役立ちます.
この記事は、問題とアプローチをうまく説明しています。
于 2009-07-06T16:08:00.177 に答える
0
非推奨として、基本的に内部、外部、パブリックの 3 種類の API があります。
内部は、コードに取り組んでいる唯一のチームです。これらの API を廃止することは大したことではありません。それを使用しているのはあなたのチームだけなので、彼らは長くは続かず、彼らを変えるというプレッシャーがあり、人々は彼らを変えることを恐れず、人々は彼らを変える方法を知っています.
外部は同じコード ベースですが、異なるチームがそれを使用している場合です。これは、大企業の一般的なライブラリや、人気のあるオープン ソース ライブラリである可能性があります。ポイントは、人々がコンパイルするコードのバージョンを選択できるということです。API の非推奨化の容易さは、組織の規模とコミュニケーションの程度によって異なります。IMO、廃止予定者の仕事は、廃止予定のマークを付けてコードベース全体に警告を飛ばすのではなく、古いコードを更新することです。なぜ非推奨者ではなく非推奨者なのですか? デッカレーターは知っているからです。彼らは何が変わったのか、なぜ変わったのかを知っています。
この 2 つのケースは非常に簡単です。下位互換性がある限り、通常は好きなことをしたり、自分でクライアントを更新したり、メンテナーにそうするよう説得したりできます。
次に、パブリック API があります。これらは基本的に、Web API など、クライアントがあまり制御できない外部 API です。これらは、更新または廃止するのが非常に困難です。ほとんどの人は壊れたことに気付かず、修正する人もいませんし、変更されたという通知も受け取らず、壊れた場合にのみ修正します (もちろん、壊れたことであなたに怒鳴った後)。
私は上記のことを数回しなければなりませんでしたが、それはとても面倒です。あなたができる最善のことは、意図的に早期に壊し、少し待ってから復元することだと思います。もちろん、最初に通常の警告と非推奨を送信しますが、信頼してください-何かが壊れるまで何も起こりません。
私がまだ試していないアイデアは、小さなテストを実行する単純なアプリを登録できるようにすることです。API の更新を行う場合は、外部テストを実行し、影響を受ける人々に連絡します。
于 2009-07-06T15:51:49.007 に答える