7

特に再利用可能なコンポーネントに関して、人々がコード ライブラリをどのように編成しているかに興味があります。以下ではオブジェクト指向の用語で話していますが、他の種類の言語のライブラリをどのように編成しているかにも興味があります。

例えば：

  • あなたはすべてのクラス ライブラリ プロジェクトに固執しますか? それとも、すべてを 1 つのプロジェクトにまとめることを好みますか?
  • ビルド済みの DLL を再利用しますか、それとも以前のプロジェクトの個々のクラスを現在の作業に含めますか? 個々のクラスの場合、それらをプロジェクト間で共有して、すべてが最新の状態に保たれるようにしますか? それとも分岐を許可しますか?
  • 再利用可能な要素の大きさは? 彼らはどのくらい集中していますか？彼らはどのように集中していますか？
  • 優先プラクティスを通じて、どのレベルの再利用を達成できますか?

等

編集

ここで特定のガイダンスを求めているわけではありません。人々の考えや実践に興味があるだけです。単一のプロジェクト内ではなく、異なるプロジェクト間でのコードの再利用に特に関心があります。(残念ながら、ここでの「プロジェクト」の使用は誤解を招きます。つまり、Visual Studio の意味でのプロジェクトではなく、顧客のために実施される実際のプロジェクト間での再利用を意味します。)

4

4 に答える 4

6

一般に、展開に関する考慮事項によってガイドできます。

どのように展開しますか (つまり、運用マシンに何をコピーしますか) ?

展開するものがパッケージ化されたコンポーネント (つまり、dll、jar、war など) である場合、「コード ライブラリ」をパッケージ化された一連のファイルのコレクションとして編成するのが賢明です。
そうすれば、実稼働プラットフォームにデプロイされる dll、jar、war などを使用して直接開発できます。
アイデアは次のとおりです。これらのパッケージ化されたファイルで動作する場合、本番環境でも動作する可能性があります。

単一のプロジェクト内ではなく、異なるプロジェクト間でのコードの再利用。

私は、その種の再利用は「コンポーネント」アプローチの方が簡単だと主張しています (「GIT のベンダー ブランチ」という質問で説明したような)。

40 以上の現在のプロジェクトで、次のことを達成しました。

  • 純粋な技術的側面を独立したフレームワーク (通常、ログ フレームワーク、例外フレームワーク、KPI - 主要業績評価指標 - フレームワークなど) に体系的に分離することによる技術的な再利用。
    これらの技術コンポーネントは、他のすべてのプロジェクトで再利用されます。
  • 明確なアプリケーションアーキテクチャを設定して、(ビジネスおよび機能仕様が与えられた場合に) 機能ドメインを明確に定義されたアプリケーションに分割することにより、機能を再利用します。これには通常、たとえば、他のプロジェクトで再利用されるサービスを公開するための優れた候補でもあるバス層が含まれます。

概要:
大規模な機能ドメインの場合、単一のプロジェクトでは管理しきれませんが、適切なアプリケーション アーキテクチャは自然なコードの再利用につながります。

于 2009-05-10T19:31:58.873 に答える
4

私たちは次の原則に従います。

  • Release-Reuse Equivalency Principle: 再利用のグラニュルはリリースのグラニュルです。
  • 共通の閉鎖原則: パッケージ内のクラスは、同じ種類の変更に対して一緒に閉鎖する必要があります。
  • 共通の再利用の原則: パッケージ内のクラスは一緒に再利用されます。
  • 非循環依存関係の原則: パッケージの依存関係グラフで循環を許可しません。
  • 安定した依存の原則: 安定の方向に依存します。
  • 安定した抽象化の原則: パッケージは、安定しているのと同じくらい抽象的であるべきです。

詳細については、こちらとこちらをご覧ください。

于 2009-05-10T19:31:55.287 に答える
0

作業するプラットフォームによって異なります。私は (誇りに思っている) Java 開発者であり、MavenやIvyなどの依存関係を整理するための優れたツールがあります。

于 2009-05-10T19:31:02.883 に答える