Javaプロジェクトで未使用/デッドコードを見つける方法[終了]

大規模なJavaプロジェクトで未使用/デッドコードを見つけるためにどのツールを使用していますか？当社の製品は数年前から開発されており、使用されなくなったコードを手動で検出することは非常に困難になっています。ただし、未使用のコードはできるだけ削除するようにしています。

一般的な戦略/手法（特定のツール以外）の提案も歓迎されます。

編集：すでにコードカバレッジツール（Clover、IntelliJ）を使用していますが、これらはほとんど役に立ちません。デッドコードにはまだユニットテストがあり、カバーされているように見えます。理想的なツールは、コードに依存する他のコードがほとんどないコードのクラスターを識別し、ドキュメントを手動で検査できると思います。

コードの使用状況のログを保持するように実行中のシステムを計測し、数か月または数年使用されていないコードの検査を開始します。

たとえば、未使用のクラスに関心がある場合、インスタンスの作成時にログを記録するようにすべてのクラスをインストルメント化できます。そして、小さなスクリプトがこれらのログをクラスの完全なリストと比較して、未使用のクラスを見つけることができます。

もちろん、メソッドレベルで実行する場合は、パフォーマンスに留意する必要があります。たとえば、メソッドは最初の使用のみをログに記録できます。これがJavaでどのように最適に行われるかはわかりません。これは、Smalltalkで行いました。これは動的言語であり、実行時にコードを変更できるようにします。すべてのメソッドをログ呼び出しで計測し、メソッドが初めてログに記録された後でログコードをアンインストールするため、しばらくするとパフォーマンスが低下することはありません。静的なブールフラグを使用してJavaで同様のことができるかもしれません...

適度に機能するEclipseプラグインは、未使用コード検出機能です。

プロジェクト全体または特定のファイルを処理し、さまざまな未使用/デッドコードメソッドを示し、可視性の変更を提案します（つまり、保護またはプライベートにすることができるパブリックメソッド）。

CodeProは最近、EclipseプロジェクトとともにGoogleによってリリースされました。無料で非常に効果的です。プラグインには、1つまたは複数のエントリポイントを持つ' Find Dead Code '機能があります。かなりうまくいきます。

私は驚いていProGuardのが、ここで言及されていません。これは、最も成熟した製品の1つです。

ProGuardは、無料のJavaクラスファイル圧縮プログラム、オプティマイザー、難読化ツール、事前検証ツールです。未使用のクラス、フィールド、メソッド、および属性を検出して削除します。バイトコードを最適化し、未使用の命令を削除します。意味のない短い名前を使用して、残りのクラス、フィールド、メソッドの名前を変更します。最後に、Java 6またはJava Micro Editionの処理済みコードを事前検証します。

ProGuardの用途は次のとおりです。

• よりコンパクトなコードを作成し、コードアーカイブを小さくし、ネットワーク間で高速に転送し、読み込みを高速化し、メモリフットプリントを小さくします。
• プログラムとライブラリをリバースエンジニアリングするのが困難になります。
• ソースコードから削除できるようにデッドコードをリストします。
• Java 6以降の既存のクラスファイルを再ターゲットおよび事前検証して、クラスの高速なロードを最大限に活用します。

デッドコードのリストの例：https : //www.guardsquare.com/en/products/proguard/manual/examples#deadcode

私がEclipseの単一のクラスで行うことで知られていることの1つは、すべてのメソッドをプライベートに変更してから、どのようなクレームが発生するかを確認することです。使用されているメソッドの場合、これはエラーを引き起こし、できる限り低いアクセスレベルに戻します。未使用のメソッドの場合、これは未使用のメソッドに関する警告を引き起こし、それらは削除できます。そしておまけとして、非公開にすることができ、非公開にする必要があるいくつかの公開メソッドを見つけることがよくあります。

しかし、それは非常に手動です。

テストカバレッジツールを使用してコードベースをインスツルメントし、テストではなくアプリケーション自体を実行します。

EmmaとEclemmaは、コードの特定の実行に対してどのクラスの何パーセントが実行されているかについての素晴らしいレポートを提供します。

Find Bugsを使用して、コードベースのターゲットが豊富なリファクタリング環境のファンクを特定できるようになりました。また、Structure 101を検討して、コードベースのアーキテクチャで複雑すぎるスポットを特定し、実際の沼地がどこにあるかを確認します。

理論的には、未使用のコードを確定的に見つけることはできません。これの数学的証明があります（まあ、これはより一般的な定理の特殊なケースです）。興味があれば、停止問題を調べてください。

これは、さまざまな方法でJavaコードに現れます。

• ユーザー入力、構成ファイル、データベースエントリなどに基づいてクラスをロードする。
• 外部コードの読み込み;
• オブジェクトツリーをサードパーティのライブラリに渡す。
• 等

そうは言っても、私はIDEAとしてIDEA IntelliJを使用しており、モジュール、未使用のメソッド、未使用のメンバー、未使用のクラスなどの依存関係を見つけるための広範な分析ツールを備えています。呼び出されないプライベートメソッドのように非常にインテリジェントです。タグ付けされた未使用ですが、パブリックメソッドはより広範な分析を必要とします。

Eclipse Goto Windows> Preferences> Java> Compiler> Errors / Warningsで
、すべてをエラーに変更します。すべてのエラーを修正します。これが最も簡単な方法です。美しさは、これにより、作成時にコードをクリーンアップできることです。

スクリーンショットのEclipseコード：

IntelliJには、未使用のコードを検出するためのコード分析ツールがあります。あなたはできるだけ多くのフィールド/メソッド/クラスを非公開にすることを試みるべきです、そしてそれはより多くの未使用のメソッド/フィールド/クラスを表示します

また、コードの量を減らす方法として、重複するコードを見つけようとしました。

私の最後の提案は、オープンソースコードを見つけることです。これを使用すると、コードが単純になります。

Structure101 スライスパースペクティブは、「メイン」クラスターとの依存関係のないクラスまたはパッケージの「孤立」または「孤立グループ」のリスト（および依存関係グラフ）を提供します。

DCDは一部のIDEのプラグインではありませんが、antまたはスタンドアロンから実行できます。静的なツールのように見え、PMDやFindBugsではできないことを実行できます。。やってみます。

PS以下のコメントで述べたように、プロジェクトは現在GitHubにあります。

コードをプロファイルし、コードカバレッジデータを提供するツールがあります。これにより、（コードの実行時に）どれだけのコードが呼び出されているかを確認できます。これらのツールのいずれかを入手して、孤立したコードの量を調べることができます。

• FindBugsは、この種のものに最適です。
• PMD（Project Mess Detector）は、使用できる別のツールです。

ただし、どちらもワークスペースで使用されていないpublic staticメソッドを見つけることができません。誰かがそのようなツールを知っているなら、私に知らせてください。

EMMAなどのユーザーカバレッジツール。しかし、それは静的なツールではありません（つまり、実際にアプリケーションを回帰テストを介して実行する必要があり、考えられるすべてのエラーケースを実行する必要があります。

それでも、EMMAは非常に便利です。

Emma、Cobertura、Cloverなどのコードカバレッジツールは、コードをインストルメント化し、一連のテストを実行することによって呼び出されるコードの部分を記録します。これは非常に便利で、開発プロセスに不可欠な部分です。これは、テストスイートがコードをどの程度カバーしているかを特定するのに役立ちます。

ただし、これは実際のデッドコードを識別することとは異なります。テストでカバーされる（またはカバーされない）コードのみを識別します。これにより、偽陽性（テストがすべてのシナリオをカバーしない場合）と偽陰性（実際のシナリオで実際に使用されないコードにテストがアクセスする場合）が発生する可能性があります。

死んだコードを本当に特定する最善の方法は、ライブ実行環境でカバレッジツールを使用してコードを計測し、長期間にわたってコードカバレッジを分析することだと思います。

負荷分散された冗長環境で実行している場合（そうでない場合は、なぜそうでないのでしょうか？）、アプリケーションのインスタンスを1つだけインスツルメントし、ロードバランサーをランダムで小さいユーザーはインストルメント化されたインスタンスで実行されます。これを長期間にわたって行うと（実際の使用シナリオ（季節変動など）をすべてカバーしていることを確認するため）、実際の使用状況でアクセスされているコードの領域と部分を正確に確認できるはずです。実際にはアクセスされないため、デッドコードになります。

私はこれが個人的に行われたのを見たことがないので、前述のツールを使用して、テストスイートから呼び出されていないコードを計測および分析する方法を知りませんが、そうであると確信しています。

Javaプロジェクト-Dead Code Detector（DCD）があります。ソースコードの場合はうまく機能しないようですが、.jarファイルの場合は非常に優れています。さらに、クラスおよびメソッドでフィルタリングできます。

ここでのNetbeansは、Netbeans デッドコード検出器のプラグインです。

未使用のコードにリンクして強調表示できればより良いでしょう。ここで投票およびコメントできます：バグ181458-未使用のパブリッククラス、メソッド、フィールドを検索します

Eclipseは、到達できないコードを表示/強調表示できます。JUnitはコードカバレッジを表示できますが、いくつかのテストが必要であり、関連するテストがないか、コードが本当に使用されていないかを判断する必要があります。

コードを計測し、使用されているコードと未使用のコードを強調表示するCloverカバレッジツールを見つけました。Google CodePro Analyticsとは異なり、これはWebApplicationsでも機能します（私の経験によると、Google CodeProについては正しくない可能性があります）。

私が気付いた唯一の欠点は、Javaインターフェースが考慮されていないことです。

私はDoxygenを使用して、呼び出されないメソッドを見つけるメソッド呼び出しマップを開発しました。グラフには、呼び出し元のないメソッドクラスタのアイランドが表示されます。常にいくつかのメインエントリポイントから開始する必要があるため、これはライブラリでは機能しません。