Javaでメソッドを適切に廃止する方法は？
今日、同僚がスーパークラスを取得するように再定義したため、使用していたメソッドを失いました。そのため、リポジトリと同期した後、問題が発生しました。この場合、メソッドを削除する代わりに@Deprecatedなどのアノテーションを使用して、メソッドが廃止されたことを通知するエラーメッセージが表示されるようにした方がよいでしょうか。バージョン管理システムまたはIDEは、メソッドを削除する代わりに非推奨にすることで、このような状況を回避できますか？
_@Deprecated_アノテーションは正しいことです。コードを削除すると、使用されているAPIに重大な変更が加えられます-これは悪いことです。
問題は、しばしば「悪い」ことを無視し、ビルドが失敗しないために非推奨のメソッドを使用することです。したがって、次に行うべき正しいことは、非推奨のメソッドを使用してビルドを失敗させることです。
Java開発者が頻繁に使用するビルドスクリプトをコンパイラの警告（エラーだけでなく）でビルドに失敗させることができます。これを行うには、使用されているビルドシステムに応じてさまざまな方法があります（ gradle、maven、ant、...）。
非推奨のメソッドを使用して（無意識のうちに）ビルドを失敗した時点で（ライブラリをアップグレードすると、何かが非推奨になり、ビルドが失敗します。これはgoodのことです）。
その時点で、非推奨の警告そのメソッド呼び出しの場合を@SuppressWarnings( "deprecation" )で明示的に無効にすると、再びビルドされます。しかし、ビルドが失敗し、APIの変更を警告するため、そのコードを修正する必要があることがわかりました。
Javaの場合、@Deprecatedアノテーション以外の非推奨の詳細はわかりません。あなたの質問に答えるために、私は少なくともメソッド自体を適切かつ明確に非推奨にすることができるGitに気づいていません（私はそれらに接触しなかったかもしれません）。私の経験では、あなた自身がそれらを使用することに慣れていたので、大量の除去方法は悪い考えかもしれません。クラスに@Deprecatedの注釈を付けると、新しいビルドへの移行期間に役立ち、すべてのチームメンバーがwhereのメソッドがなくなったこととその理由を明確に確認できます。いつ、なぜ、どのようにメソッドが廃止されたのかについてアノテーションにコメントすることも良い考えです。
非推奨は、チーム環境の単一プロジェクト内での使用を目的として設計されていません。 公開API向けに設計されています 。単一のプロジェクト内では、 Mothermole1の回答 に示すように、そのAPIを使用するより良い方法があることを示すのに役立ちます。 この質問 は、メソッド/クラスが廃止された理由と代替として何を使用すべきかを適切に文書化する方法に関するいくつかの提案があります。
問題のメソッドが削除された状況について、もう少し詳しく知りたいと思います。私の頭では、そのコードが存在していた期間と、それがアプリにとってどれほど重要であるかによって、その除去にどの程度の儀式を付加する必要があるかが決まります。それが他の1つの場所で使用されており、かなり新しいものである場合、その削除のプロセスは期待できません。ただし、それが何年も前から存在し、アプリ全体で使用されるコアクラスの一部である場合、移行を最適に処理する方法についての議論が期待されます。
それにはいくつかの方法があります。問題のメソッドがアプリの外部にエクスポートされるパブリックAPIの一部である場合、最善の方法は通常、あるリリースでメソッドを廃止し、次のリリースで削除することです。多くの場合、下位互換性のためにメソッドを削除することはありません。もはやサポートされていないことを明確にするだけです。内部APIでは、使用がどれだけ普及しているか、変更がどれほど複雑であるかに応じて、それを削除してすべての呼び出し元を修正します。呼び出しが多くの場所で使用されており、サポート終了を変更するのが難しい場合は、おそらくより安全な賭けです。プロジェクトには2つの異なる方法があるため、プロジェクトに追加する可能性のある技術的負債を確認してください。長期間にわたってコードを移行する移行戦略を検討することもできます。