0

大量のサード パーティの依存関係を持つかなり大規模な Java エンタープライズ プロジェクトを継承しようとしています。少なくとも 70 個の JAR が含まれており、そのうちのいくつかは使用されていないように見えます。

何年にもわたって、さまざまな開発者がコード ベースに触れてきたので、彼ら全員が今月のプロジェクトの新しいタイプ ライブラリを試してきたようです。

これらを取り除くにはどうすればよいでしょうか。もちろん、車輪を再発明する必要がないために、いくつかの依存関係が役立つことは明らかです。

私は明らかにJavaベースのプロジェクトに興味がありますが、人々が役立つと思う言語を超えた回答を歓迎します.

4

7 に答える 7

4

個人的には、問題の規模を評価することから始めなければならないと思います。かなり面倒ですが、依存関係のリストを作成し、プロジェクトのどの部分がどの部分を使用しているかを正確に把握します。

次に、実際に使用しているそれぞれの機能を正確に把握します (多くの場合、使用している大規模なサード パーティ製ライブラリのごく一部を使用することになります)。

この情報があれば、少なくとも自分が何を扱っているかがわかります。

私の次のステップは、ごくわずかしか使用していないすべての依存関係を調べることです。調べてみると、あまり使用されていないライブラリを排除する他のライブラリから使用できるものが明らかになる場合があります。

また、書き直して独自のコードベースに含めることができる小さなものがあるかどうかを確認するために、周りを見回したいと思います.

最後に、依存関係のベンダーとその競合他社を調べて、最新バージョンに他のいくつかを排除できる機能が追加されているかどうかを確認します。

それでは、少数のベンダーに大きく依存する方が良いのか、多くのベンダーへの依存度が低い方が良いのか、疑問に思うだけです!! ;o)

于 2008-10-10T14:04:48.857 に答える
2

structure101 http://www.headwaysoftware.com/products/structure101/index.php 依存関係を表示するための優れたツールです。私はそれを数年間使用しています。

于 2008-10-10T15:47:30.957 に答える
1

自動化されたテストの適切なセットがあり、まったく使用されていないライブラリを削除しようとしている場合は、試行錯誤を行うことができます。ライブラリを 1 つずつ削除し、テストを実行して、すべてがまだ機能するかどうかを確認します。そうでない場合は、元に戻します。もちろん、ライブラリなしでビルドすることさえできない場合は、おそらくライブラリが必要です。

基本的には、どのように進めても、一度に 1 つずつ削除して、何が壊れているかを確認するというのが私の考えです。何も壊れない場合は、ライブラリを放り投げることができる可能性が高くなります。問題が非常に小さい場合 (たとえば、大規模なライブラリで 1 つのクラスの 1 つのメソッドが必要な場合) は、コードで回避できる可能性があります。

スタンドアロン アプリケーションを扱っている場合は、JVM に -verbose:class オプションを指定して、どのクラスがロードされているかを確認できます。これにより、次のようなメッセージが表示されます。

[Opened C:\Program Files\Java\jre1.6.0_04\lib\rt.jar]
[Loaded java.util.regex.Pattern$Single from C:\Program Files\Java\jre1.6.0_04\lib\rt.jar]
于 2008-10-10T14:44:22.020 に答える
1

ここで、インストルメンテーションを使用したアプローチについて読みましたが、試したことはありませんが、合理的に聞こえます。

于 2008-10-10T14:53:31.207 に答える
1

Delphi コードベースで、このような演習を行いました。外部依存関係を大幅に簡素化しました。基本的には、次のように進めました。

  • すべての外部ライブラリとコンポーネントをカタログ化
  • (ファイル検索ツールを使用して) カタログ化された、それらが使用された場所と目的。
  • 使用していない、または不要なものをすべて削除しました (一部のライブラリは、不要になったコードで使用されていました)。
  • ライブラリが積極的に開発されたかどうか、使用した機能の量、それを使用するコードを既に使用している別のライブラリに移植するのがどれほど難しいかなどに基づいて、どのライブラリを優先するかをランキングしました。
  • 最後に、その機能を別のライブラリに移植することにより、リストの下位にあるライブラリへの依存関係を繰り返し削除しました。

とはいえ、これはかなりの労力でした。

于 2008-10-10T14:56:21.123 に答える
1

「コンパイルされなくなるまで何かを削除する」というアプローチを取る場合は、推移的な実行時の依存関係に細心の注意を払う必要があります。高品質のテスト スイートがあれば役に立ちますが、Cobertura などのテスト カバレッジ ツールを実行して、完全な依存関係グラフを実行するのに十分なコードがテストされていることを確認する必要があります。

どのくらいのコードについて話しているのですか？率直に言って、Joeri によって提案されたレビューベースのアプローチは、私にとって最良のように思えます。少なくとも表面的にはシステムのすべての部分に慣れるという追加の利点があります。大きなプロジェクトを引き継いでいるだけなら、とにかく時間をかけるべきでしょう。

于 2008-10-10T16:07:54.800 に答える
0

このプロジェクトの完全な回帰テスト スイートがある場合は、ループのたびに 1 つ少ない JAR で実行しながら、回帰スイートを実行するだけです。高速ではありませんが、簡単に実行できます。

于 2008-10-10T16:45:19.280 に答える