この問題は、静的ではなく動的な Java の依存関係です。このstackoverflowリンクを読みましたが、これは静的依存関係に関するものであり、グーグルで検索すると同様の結果が得られます。
だからここに私の問題があります：
これは、現在 50 人以上の開発者と共に 10 年間実行されている非常に大きなプロジェクト (2 万以上の Java ファイル) です。ここでは常に再構築が行われるため、レイヤーの新しいスタックと古いスタックがあります。ほとんどの場合、リスク軽減とは、クラスをすぐに取り除くことができないことを意味します。代わりに、calle メソッドは新しいクラスと古いクラスの両方への呼び出しを保持します。開発者への標準的な指示は、本番環境でのアプリケーションの実行中に古いクラスを呼び出すべきではありません。
現在の回避策:
彼らがしていることは、古いクラスに「偽旗」を掲げ、それが呼び出されないように祈ることです。そうなった場合 (開発者が新しいクラスを指し示すのを忘れる可能性があるため)、本番環境で問題が発生した場合は、古いクラスに対するフラグを true に設定すると、すべてがうまくいきます。(この方法では、フラグを持つプロパティ ファイルを変更するだけで、再コンパイルする必要はありません) prod でこのようなテストを 1 年ほど行った後、古いクラス ファイルを手放しました。これは技術的には最善のアプローチではないかもしれませんが、実際にはミッションクリティカルなアプリではチャンスを逃し、これらの 20K クラスが Java で何をしているのか、あるいは機能的に何をしているのかを覚えている/知ることができる人は誰もいません。
私が探しているもの：
未使用のクラスを見つけるためのツールまたは方法。
特定のまれなシナリオを実行するまで、実行時にどの古いクラスが呼び出されているのか、したがって既存のソリューションが見つからないため、これはいくつかの点で鶏卵です。
PMD などの静的コード分析ツールを使用する場合、少なくともコード レベルで実際に一部または他のクラスによって呼び出されているため、未使用のものは通知されません。
たぶん、そしてその単なるワイルドな考えですが、トップレベルのアクションレイヤーから始まるすべての依存関係チェーン/ツリーをトラバースし、結果を取得するツール
そしてもちろん、リアクティブな方法は、完全に自動化された回帰テスト スイートを構築し、可能なすべてのシナリオを実行することですが、残念ながら予算や人的制限などにより、ここでは不可能です。
私が必要としているのは、コードを最適化する積極的な方法です。これは可能であるという希望的観測かもしれませんが、この問題はランダムでも構造化されたものでもないので、どこかに解決策があるかもしれないというしつこい感覚があります。
どんな考えでも大歓迎です。!!