5

まず、C＃からJavaに（戻って）来ているので、私の用語や哲学が完全に一致していない場合はお詫びします。

背景は次のとおりです。Web用に作成された内部サポートツールのコレクションが増えています。フロントエンドにはHTML5/AJAX /その他の流行語を使用し、バックエンドにはJavaを使用します。これらのツールは、軽量の社内フレームワークを利用しているため、セキュリティやその他の構成のための管理インターフェイスを共有できます。各ツールは別々の作成者によって作成されており、この傾向は今後も続くと思います。そのため、将来の作成者が、すでに使用することを決定したサードパーティのライブラリで「標準化」された状態を維持できるようにしたいと思います。 DI、単体テスト、ORMなど。

現在、パッケージの名前は次のようになっています。

  • com.ourcompany.tools.framework
  • com.ourcompany.tools.apps.app1name
  • com.ourcompany.tools.apps.app2name

...等々。

だからここに私の質問があります：これらのアプリ（およびフレームワーク）のそれぞれは、Mavenセットアップ、Eclipseなどの目的のために別々のプロジェクトとして扱われるべきですか？

時間の経過とともに多くのアプリがここに表示される可能性があるため、分離することで依存関係がよりクリーンに保たれ、誰かが1つのツールに簡単にアクセスできるようになります。一方、（1）パッケージ構造のより深い部分を複数のプロジェクトに「分割」することはコードの臭いであり、（2）それらを組み合わせておくと、ツール作成者は他のプロジェクトにすでに配置されているサードパーティのライブラリを使用する傾向が強くなります。ツール。

FWIW、私の最初の本能はそれらを分離することです。

Javaの達人、何て言うの？

4

5 に答える 5

7

私は絶対にそれらを分離します。Mavenの目的のために、各アプリ/プロジェクトがフレームワーク/アプリへの適切な依存関係を持っていることを確認してください。これにより、単一のアプリを作成するだけですべてを作成する必要がなくなります。

于 2012-07-02T16:42:35.237 に答える
3

私はプロジェクトを分離したままにしますが、すべての依存関係と他の一般的なプロパティを含めるために親pomを使用します。個々のツール/プロジェクトには、親プロジェクトへの名前と参照、およびプロジェクト固有の依存関係がある場合はそれがあります。これは、共通のライブラリと依存関係を維持するのに役立ちます。これは、共通のライブラリと依存関係がすでにすべて構成されているためですが、作業する必要のあるコードベースの特定の部分に集中できます。

于 2012-07-02T16:45:56.163 に答える
2

私は間違いなくこれらの種類のものを別々のプロジェクトに分けたいと思います。

Mavenを使用して、依存関係/ビルドプロセスを自動的に処理する必要があります（独自の内部共有ライブラリとサードパーティの依存関係の両方）。複数のアプリケーションが同じ共有ライブラリを参照していても問題はありません。必要に応じて、複数のバージョンを保持することもできます。

このアプローチからのいくつかのボーナス：

  • これにより、共有プロジェクトのAPI設計について慎重に検討する必要があります。これは、長期的には良いことです。
  • また、ソースコード管理の適切な粒度についても説明します。つまり、開発者は特定のアプリケーションやバックエンドモジュールを個別にチェックアウトして作業できます。
于 2012-07-02T16:47:54.780 に答える
1

複数のプロジェクトで使用される可能性が高いプロジェクトのセクションがある場合は、それを引き出すのが理にかなっています。一般的に使用されるプロジェクトの1つでコードを更新する必要がある場合にも、少しクリーンになります。

于 2012-07-02T16:44:58.270 に答える
0

それらを一緒に保つと、ツールの開発、構築、および展開の障害が少なくなります。

逆の状況で、多くの別々のプロジェクトがありました。それらを1つのプロジェクトツリーにマージした後、私たちははるかに生産性が高くなります。これは、流行しているどのような慣習よりも重要です。

于 2012-09-07T04:23:09.560 に答える