分離Javaプロジェクト
大規模なJava=プロジェクトがあり、ビルドサイクルにmavenを使用しています。この1つのプロジェクトは、他のプロジェクトやさまざまなアプリケーションで広く使用されています。他の場所にあります...正直に言うと、それは少し混乱しています（特定の目的のためにさまざまな時間に追加されるさまざまなビット）。少しクリーンアップしたいと思います。また、完全にテストされていません（多くのビット）適切なユニットと統合テストなしで追加されました）、そして実行に時間がかかる、または実際にパスしないテストがあります...（ええと）-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 /何でも）を使用するかどうかに関係なく、非常に重要です。
まず、Maven依存関係プラグインから広範なレポートを取得して、取得した内容を確認します。一般的に言えば、POMの依存関係管理で依存関係を可能な限りフードチェーンの上位に設定しますが、それより高くすることはできません。したがって、2つのサブモジュールが外部依存関係を使用している場合は、それを親POMに持ち込み、以下同様に続きます。
外部JARのアップグレードは、常に適切なミニプロジェクトとして行う必要があります。アップグレードする理由を評価し、新しい機能やバグ修正などを利用するためにソースコードを変更します。この分析と作業なしでバージョンをバンプするだけで問題が発生します。
だから、一般的に、私の質問は：
大規模なプロジェクトを分割した経験はありますか？共有したい>ヒント/コツはありますか？
- インターフェースと依存性注入はあなたの友達です。
- レガシーコードで効果的に対処するマイケルフェザーの本 は必読です。
- 統合テストはあなたの友達です
- サブプロジェクトをfoo-api（インターフェースのみ！）とfoo-coreに分割し、モジュールがfoo-apiのみに依存するようにすると、非常に役立ち、分離が強制されます
- Jbossモジュールおよび/またはOSGiは、クリーンな分離の実施に役立ちます
これは開発とビルド時間にどのような影響を与えましたか？
開発時間とビルド時間への非常に小さな影響-継続的デリバリーパイプライン全体の時間の大幅な増加。
このようなプロジェクトの分割を構築する上で、どのようなアドバイスを提供できますか？
ささいなことを正しく行うと、大きなことはその後きれいに抜ける傾向があります。ですから、少しずつ物事を分割してください。統合テストのカバー率が高い場合を除いて、ロット全体の大規模な再構築を行わないでください。
分割前に統合テストを作成します-分割後も同じ結果が得られるはずです。
現在のモジュール性と到達したい場所の図を描きます。中間ステップを設計します。
あきらめないでください-ヤクの一部のシェービングは、「恐怖なしに迅速にビルドおよびリファクタリング」するための基盤を構築しますShamelessプラグ-> Benおよび私は The Well-Grounded Java Developer です。
がんばって！
これに対する私の見解は、必要な場合にのみ分離されます。ただし、次の質問が表示されます。必要かどうかはどのように判断するのですか？
- アーティファクトが異なる場合（つまり、EAR、WAR、JAR、integration-testing-jarを同じプロジェクトでビルドしないでください）。
- 分離中に、いくつかのコードが複数のアーティファクトに存在する必要があることに気づいたとき、それらを新しいものにリファクタリングします。
- チーム外の他のプロジェクトが、プロジェクトで使用しているものを使用したい場合。
1つの理由は、開発者が複数のプロジェクトに対処し、Javaパッケージはどのプロジェクトに属すべきかということを別として考えなければならないことです。私はそれが本当に貧弱になり、たった4つのクラスが1つの機能を実装しているプロジェクトがありました。これは、アーキテクチャの方向性のためです。これは、Mavenが普及する前にも遡るので、クラスパスとIDE =およびAntスクリプト。
もう1つの理由は、ファイルを配管することに関して、より多くの可動部分を処理する必要があり、それを知る前に依存関係のスパゲッティを持っている可能性があることです。
リファクタリングは、プロジェクト全体ではなく、プロジェクト内でも簡単です。
ビルド時間が問題になる場合は、より優れたハードウェアを提供してください。