Javaで非推奨にするタイミングと削除するタイミング

リファクタリングの努力または継続的な開発の一環として、特定のメソッドまたはクラス全体が何らかの意味で廃止される可能性があります。Javaは@Deprecated注釈をサポートして、問題の機能を処理するより良い方法があることを示します。これは、APIの一部を削除した場合の影響がわからないかもしれないパブリックAPIで特に役立つと思います。非パブリックAPIおよびリビジョン管理システムを使用するプロジェクトの場合（削除は何らかの意味で元に戻すことができます）、廃止された要素を削除するのではなく、廃止するのが適切なのはいつですか？

あなたのAPIは公開APIですか？それはあなたが非推奨または削除すべきかどうかを決定します。APIが厳密にあなたの利益のためにある場合（つまり、社内でのみ使用される場合）、問題のコードを単に削除するのが最善です。それははるかにきれいで、長期的にはメンテナンスの頭痛の種が少なくなります。

ただし、APIが公開されている場合、メソッドを削除するだけで、以前のバージョンのライブラリで動作していたコードが動作しなくなる可能性があります。それは物事が乱雑になる場所です。以下にいくつかのガイドラインを示します。

• 内部API：非推奨ではなく削除。クライアントが内部クラスまたはメソッドを使用している場合、ツールが壊れてもそれは彼らのせいです。
• 外部API：最初に廃止し、後で削除します。廃止は、何かが後で削除されることを示すフラグです。後であなたが合理的であると信じるものに依存します。少なくとも、非推奨コードを実際に削除する前に、2〜3バージョンを提供してください。

クラスまたはメソッドを@deprecateするときにリマインダーを設定することをお勧めします。その陳腐化を促進するためにそれをしている。そのため、すべての参照を削除するために、空いた時間にタスクを実行するのにかかる時間を推測してください。@deprecatedとしてマークし、カレンダーにリマインダーを入れます。リマインダーを取得したら、確認してください。使用されなくなった場合は削除します。すぐに更新できる参照がいくつか残っている場合は、それを実行してアイテムを削除します。さらに重要な作業が残っている場合は、リマインダーを少し前に進めます。

これを十分に行うと、プロジェクト内のクラスまたはメソッドを削除するのにかかる時間の感覚を身に付けることができます。

私見では、誰もそれを使用していないことを確認できる場合、それを削除しないでください。（これは、リフレクション、またはVelocityマクロなどの外部コンポーネントが存在する場合に注意が必要です。IntelliJなどの最新のIDEは、リフレクションやVelocityではなくJSPなどで参照を見つけることができます。）

より良い代替手段があるが、古いものがまだ多くの場所で使用されており、現在すべてのクライアントコードをリファクタリングする時間がない場合は、廃止されたクラス/メソッドを@deprecateするのが適切です（適切なコメント付き）好ましい選択肢）。