Javaプロジェクトの分離

大規模なJavaプロジェクトがあり、ビルドサイクルにmavenを使用しています。この1つのプロジェクトは広く使用されています-他のプロジェクト、さまざまなアプリケーション、その中に含まれているものと他の場所にあるもの...正直に言うと、それはちょっとした混乱です目的）、そして私はそれを少しきれいにしたいと思います。また、完全にはテストされていません（適切なユニットおよび統合テストなしで多くのビットが追加されています）。実行に時間がかかるか、実際に合格しないテストがいくつかあります...（uh-oh）-そうテストはMavenビルドサイクルでオフに切り替えられます（繰り返しますが）。

「最終」サブプロジェクト（または複数のサブプロジェクト）が必要とするさまざまなサブプロジェクトを選択できるように、この大きなプロジェクトを小さな特定のプロジェクトに分割することを考えています。

私の考えは次のとおりです。

• 大きなプロジェクトをさまざまなサブプロジェクトに分けると、各プロジェクトの責任が明確になります。
• サブプロジェクトに分けることで、各サブプロジェクトのテストを個別にクリーンアップし、Mavenビルドサイクルでそのサブプロジェクトのテストを有効にできます。

これがビルド時間に与える影響について少し懸念しています。

• 大きなプロジェクトに構造を課す（つまり、小さなサブプロジェクトに入れる）と、コンパイラの速度が低下しますか？

また、IDEでの編集時間にどのような影響があるかも少し懸念しています（主にIntellijを使用しています）。Intellijは依存関係ツリーを介して各プロジェクトを順番にビルドするようです。つまり、CがBに依存し、Aに依存し、Aを変更すると、Aがコンパイルしない限りBをビルドしようとしません。おそらくそれは有利ですが、たとえば、BおよびCで広く使用されているAのインターフェイスを変更すると、その変更によるすべてのエラーを修正するのに時間がかかることがわかりました...

もう1つの質問は、ファクトリクラスの使用方法です。プロジェクトの一部の側面は外部jarに依存しています。時折（ありがたいことに頻繁に）これらは更新され、移行する必要があります。外部コードの正しいバージョンを指すFactoryクラスを使用してこれを処理する傾向があります（したがって、コードベース全体のすべての実装を変更する必要はありません）。

現時点ではこれはすべて大規模なプロジェクトですが、サブプロジェクトに切り替えることで、新しい外部コードを実装するための新しいプロジェクトを開発し、サブプロジェクトが完全に機能し、テストされていることを確認できます。次に、ユーザープロジェクトの依存関係/ファクトリクラスを切り替えます。ただし、大規模なプロジェクト全体でインターフェイスを広範囲に使用するため、これはより複雑になります。例えば

• サブプロジェクトA-インターフェースを含む
• サブプロジェクトB-インターフェースと古い外部jarはAに依存
• サブプロジェクトC-B（およびAおよび古い外部jar）に依存し、Bのインターフェース実装を使用するFactoryクラスを含む

Bの外部jarを変更する必要がある場合、次のことができます。

• サブプロジェクトB_iiの作成-再びAに依存し、新しい外部jar
• 完全に機能したら、Cの依存関係をB_iiに追加し、インターフェイスの新しい実装を使用するようにFactoryクラスを変更できます。

• すべてが機能したら、Cの元のBへの依存関係を削除し、必要に応じてサブプロジェクトBを削除できます。

• これは賢明な方法ですか？

だから、一般的に、私の質問は次のとおりです。

• 大規模なプロジェクトを解体した経験はありますか？共有したいと思うヒント/トリックはありますか？
• これは開発およびビルド時間にどのような影響を与えましたか？
• このようなプロジェクトのこのような分裂を構造化する上で、どのようなアドバイスを提供できますか？

私はこれで簡単な最初のカットを取るつもりです（素晴らしいQ BTW！）：

大きなプロジェクトに構造を課す（つまり、小さなサブプロジェクトに入れる）と、コンパイラの速度が低下しますか？

重要なことではありませんが、オーバーヘッドは実際にはMavenの呼び出しにあります。

また、IDEでの編集時間にどのような影響があるかも少し懸念しています（主にIntellijを使用しています）。Intellijは依存関係ツリーを介して各プロジェクトを順番にビルドするようです。つまり、CがBに依存し、Aに依存し、Aを変更すると、Aがコンパイルしない限りBをビルドしようとしません。おそらくそれは有利ですが、たとえば、BおよびCで広く使用されているAのインターフェイスを変更すると、その変更によるすべてのエラーを修正するのに時間がかかることがわかりました...

異なるIDEには、Mavenバインディングと依存関係管理に関して異なる長所があります。現在のプレイ状態は、ほとんどが最新のEclipse、Netbeans、IntelliJで動作するように見えますが、開発者に「ディスクからソースファイルを更新し、関連するすべてのMavenプロジェクトを再構築する」という緊急の二重の苦労を教える必要があります。

しかし、最近ではその必要性が減っています。ここで、SSDドライブを使用すると、大きな違いが生じます。

工場クラスの段落を切り取る

依存関係管理は、実装に役立つテクノロジー（Maven / Ivy / whatever）の使用に関係なく、非常に重要です。

Maven依存関係プラグインから広範なレポートを取得することから始めて、あなたが持っているものを検討します。一般的に、POMの依存関係管理では、食物連鎖のできるだけ高い位置に依存関係を設定しますが、それ以上は設定しません。したがって、2つのサブモジュールが外部依存関係を使用している場合、それを親POMなどに持ち込みます。

外部JARのアップグレードは、常に適切なミニプロジェクトとして実行する必要があります。アップグレードの理由を評価し、ソースコードを変更して新しい機能やバグ修正などを活用します。この分析と作業を行わずにバージョンを変更するだけで問題が発生します。

だから、一般的に、私の質問は次のとおりです。

大規模なプロジェクトを解体した経験はありますか？>喜んで共有できるヒント/トリックはありますか？

• インターフェイスと依存関係の注入はあなたの友達です。
• レガシーコードを効果的に扱うためのMichael Featherの本は必読です。
• 統合テストはあなたの友達です
• サブプロジェクトをfoo-api（インターフェースのみ！）とfoo-coreに分割し、モジュールがfoo-apiのみに依存するようにすると、非常に役立ち、分離が強制されます
• Jbossモジュールおよび/またはOSGiはクリーンな分離を実施するのに役立ちます

これは開発およびビルド時間にどのような影響を与えましたか？

開発およびビルド時間への非常に小さな影響-継続的な配信パイプライン全体の時間の大幅な増加。

このようなプロジェクトのこのような分裂を構造化する上で、どのようなアドバイスを提供できますか？

ささいなことを正しくすれば、大きなものはきれいに落ちてしまう傾向があります。だから、少しずつ物事を分割してください-統合テストのカバレッジの割合が高くない限り、ロット全体の大規模な再構築をしないでください。

分割前に統合テストを作成します-分割後に多少なりとも同じ結果が得られるはずです。

現在のモジュール性と到達したい場所の図を作成します。中間ステップを設計します。

あきらめてはいけない-いくつかのヤクのシェービングは今、「急速にビルドとリファクタリング恐れなし」にできることのための基盤構築する恥知らずなプラグインを - >ベンから、私はだまあ接地Java開発。

幸運を祈ります！

これに関する私の見解は、必要な場合にのみ分離されます。しかし、それは次の質問を提起します：それが必要であるかどうかをどのように判断しますか？

• 成果物が異なる場合（つまり、同じプロジェクトでEAR、WAR、JAR、integration-testing-jarをビルドしないでください）。
• 分離中に、いくつかのコードが複数のアーティファクトに存在する必要があることに気付いたとき、それらを新しいものにリファクタリングします。
• チーム外の他のプロジェクトが、プロジェクトにあるものを使用したい場合。

その理由の1つは、開発者が複数のプロジェクトに対処し、どのJavaパッケージがどのプロジェクトに属するべきかは別として把握しなければならないことです。私はそれが本当に貧弱になったプロジェクトに携わっており、それがアーキテクチャの方向だからという理由だけで、1つの機能を実装する4つのクラスを持つプロジェクトがありました。これは、Mavenが一般的になる前に戻っていたため、クラスパスと、IDEスクリプトとAntスクリプトの両方で設定する必要のないものがありました。

もう1つの理由は、ファイルを配管するという点で対処する必要がある可動部分が多くなり、気付かないうちに依存スパゲッティを持っている可能性が高いことです。

リファクタリングは、プロジェクト間ではなくプロジェクト内でも簡単です。

ビルド時間が問題になる場合は、より優れたハードウェアを提供してください。