私は、既存のJavaプロジェクトのコードカバレッジを増やすように依頼されました。
コードカバレッジツール（EclEmma）が、どこからも呼び出されないメソッドを強調していることに気付きました。
私の最初の反応は、これらのメソッドの単体テストを書くことではなく、ラインマネージャー/チームにそれらを強調し、これらの機能がそもそもなぜあるのかを尋ねることです。
最善のアプローチは何でしょうか？それらの単体テストを作成するか、それらがなぜ存在するのか疑問に思いますか？
回答:
根拠：
コメントからの警告：元の答えは、コードが間違いなく死んでいることを徹底的に検証したと仮定していました。IDEには誤りがあり、実際には死んでいるように見えるコードが呼び出される可能性のある方法がいくつかあります。確信がない限り、専門家を招いてください。
他のすべての回答は、問題のメソッドが実際には使用されていないという仮定に基づいています。ただし、このプロジェクトは、このプロジェクトが自己完結型であるか、何らかのライブラリーであるかを指定しませんでした。
問題のプロジェクトがライブラリの場合、一見使用されていないメソッドがプロジェクトの外部で使用される可能性があり、それらを削除すると他のプロジェクトが破損します。ライブラリ自体が顧客に販売されているか、公開されている場合、これらの方法の使用を追跡することさえ不可能になる場合があります。
この場合、4つの可能性があります。
filter_name_exists、ReloadSettingsまたはaddToSchema（3つの任意のオープンソースプロジェクトからランダムに選択された）のようなメソッド名は、メソッドが何をすべきかについてのヒントを提供する必要があります。javadocコメントはさらに便利です。適切な仕様ではありませんが、少なくともリグレッションを防ぐことができるいくつかのテストを作成するには十分かもしれません。
まず、コードカバレッジツールが正しいことを確認します。
私は、インターフェースへの参照を介して呼び出されるメソッドで、またはクラスがどこかに動的にロードされる場合、それらがピックアップされない状況がありました。
Javaは静的にコンパイルされるため、メソッドを削除してもかなり安全です。デッドコードを削除することは常に良いことです。実行時にそれらを実行するクレイジーなリフレクションシステムが存在する可能性があるため、最初に他の開発者に確認してください。
invokedynamic命令もあるので、知っています
最善のアプローチは何でしょうか？それらの単体テストを作成するか、それらがなぜ存在するのか疑問に思いますか？
コードを削除するのは良いことです。
コードを削除できない場合は、確実に@Deprecatedとしてマークし、メソッドを削除するためにターゲットにしているメジャーリリースを文書化できます。その後、「後で」削除できます。それまでは、それに依存する新しいコードを追加しないでください。
非推奨のメソッドに投資することはお勧めしません。カバレッジターゲットを達成するためだけの新しいユニットテストはありません。
2つの違いは主にメソッドが公開されたインターフェースの一部であるかどうかです。公開されたインターフェイスの一部を任意に削除すると、インターフェイスに依存していた消費者にとって不快な驚きになる可能性があります。
私はEclEmmaに話すことはできませんが、私の経験から、あなたが注意する必要があることの1つは反射です。たとえば、テキスト設定ファイルを使用して、アクセスするクラス/メソッドを選択する場合、使用/未使用の区別が明確でない場合があります（結合された時代に焼かれました）。
プロジェクトが依存関係グラフのリーフである場合、非推奨のケースは弱められます。プロジェクトがライブラリの場合、非推奨のケースはより強力です。
会社でmono-repoを使用している場合、複数レポの場合よりも削除のリスクが低くなります。
l0b0で述べたように、ソース管理でメソッドが既に利用可能な場合、削除後にメソッドを回復するのは簡単な作業です。本当にそうする必要があるか心配なら、必要に応じて削除された変更を回復できるようにコミットを整理する方法を考えてください。
不確実性が十分に高い場合は、コードを削除するのではなく、コメントアウトすることを検討できます。ハッピーパス（削除されたコードが復元されることはありません）での余分な作業ですが、復元が容易になります。私の推測では、それによって何回か焼かれるまでは、完全削除を好むはずです。これにより、このコンテキストで「不確実性」を評価する方法についての洞察が得られます。
なぜ彼らがそこにいるのか疑問？
伝承の獲得に費やされた時間は、必ずしも無駄ではありません。私は2つのステップで削除を実行することが知られています-最初に、コードについて学んだことを説明するコメントを追加してコミットし、その後コード（およびコメント）を削除します。
また、ソースコードで伝承をキャプチャする方法として、アーキテクチャ決定レコードに類似したものを使用することもできます。
コードカバレッジツールは、すべてを把握しているわけではありません。ツールがメソッドが呼び出されていないと主張しているからといって、メソッドが呼び出されていないわけではありません。リフレクションがあり、言語によってはメソッドを呼び出す他の方法があるかもしれません。CまたはC ++では、関数名またはメソッド名を構成するマクロが存在する場合があり、ツールが呼び出しを認識しない場合があります。したがって、最初のステップは次のとおりです。メソッド名および関連する名前をテキスト検索します。経験豊富な同僚に尋ねてください。実際に使用されている場合があります。
不明な場合は、各「未使用」メソッドの先頭にassert（）を配置します。たぶん呼び出されます。またはロギングステートメント。
たぶん、コードは実際に貴重です。同僚が2週間作業を続けていて、明日は同僚が作業を開始する新しいコードかもしれません。明日は追加される予定なので、今日は呼び出されません。
たぶん、コードは実際に貴重なパート2です。コードは、物事がうまくいかないことを見つけることができる非常に高価なランタイムテストを実行している可能性があります。実際に問題が発生した場合にのみ、コードがオンになります。貴重なデバッグツールを削除している可能性があります。
興味深いことに、可能な限り最悪のアドバイス「削除、コミット、忘れて」。最高評価です。（コードレビューですか？コードレビューをしていませんか？コードレビューをしていない場合、一体何をプログラミングしていますか？）
ソフトウェアが実行される環境に応じて、メソッドが呼び出されたかどうかを記録できます。適切な期間内に呼び出されない場合、メソッドは安全に削除できます。
これは、メソッドを削除するよりも慎重なアプローチであり、障害に敏感な環境で実行している場合に便利です。
#unreachable-code削除の候補ごとに一意の識別子を使用して専用のスラックチャネルにログを記録します。これは非常に効果的であることが証明されています。