問題タブ [project-organization]

プロジェクト ディレクトリを整理する一般的な方法の 1 つは、多かれ少なかれ次のようなものです。

app.cpp:

.h同じライブラリのファイルはすべて.cpp同じディレクトリにあります。名前の衝突を避けるために、ファイル名には多くの場合、会社名やライブラリ名がプレフィックスとして付けられます。MyLib は MyApp のヘッダー検索パスなどに含まれます。私はファイル名にプレフィックスを付けるのは好きではありませんが#include、ヘッダー ファイルがどこに属しているかを正確に把握するために、. ファイルを整理するこのアプローチは嫌いではありませんが、もっと良い方法があるはずだと思います。

新しいプロジェクトを開始するので、ディレクトリ構成のアイデアを募集したいと思います。現在、私はこのディレクトリ構造が好きです:

app.cpp:

.cppファイルとプライベート (即時ライブラリにのみ表示される).hファイルは、src ディレクトリ (src は lib と呼ばれることもあります) の下に格納されます。パブリック ヘッダー ファイルは project/lib ディレクトリ構造に編成され、<ProjectName/LibraryName/headerName.h>. ファイル名の前に何も付けません。他のチームが使用できるように MyLib をパッケージ化する必要が生じた場合は、makefile を変更して、適切なバイナリ ファイルと include/ProjA ディレクトリ全体をコピーするだけで済みます。

ファイルがソース管理にチェックインされ、人々がファイルの作業を開始すると、ディレクトリ構造を変更するのは難しくなります。初めのうちはきちんとしたほうがいいです。

このようなソース コードを整理した経験のある人はいますか? 気に入らない点はありますか？もっと良い方法があれば、ぜひ教えていただきたいです。

プロジェクト内のファイルを整理する最良の方法は何ですか?

たとえば、すべてのユーザー コントロールを別のフォルダーに配置しますか?それともサブ フォルダーに配置しますか? ビジネス ロジック フォルダはありますか? ヘルパー クラス フォルダー？

私は自分のプロジェクトを次のように整理していました。

プロジェクト/ユーザー コントロール/モジュール名/プロジェクト/クラス/モジュール名/

今、私はこのようなものに向かってもっと学んでいます: Project/Module Name/User Controls/ Project/Module Name/Classes/

最善の方法は何ですか？特にプロジェクトが本当に大きくなった場合は？どのタイプのフォルダ構造が存在する必要がありますか?

私の会社では、各データベース オブジェクト (ストアド プロシージャ、ビューなど) を個別の SQL ファイルとして保存し、そのようにソース管理下に配置しています。

これまで、バージョン管理されたファイル構造には非常にフラットなストレージ モデルがありました。

• DatabaseProject
  • Functions
    • (すべての関数がここにあり、それ以上のネストはありません)
  • StoredProcedures
    • (すべてのストアド プロシージャがここに含まれます。それ以上のネストはありません)
  • Views
    • （同上）

大きな新しいプロジェクトのために、別のアイデアが思い浮かびました。プレハブのフラット リストではなく、件名ごとにこれらのファイルを保存してみませんか?

例えば：

• DatabaseProject
  • Reports
    • (個々のストアド プロシージャ、ビューなど)
    • SpecificReport
      • (ここにオブジェクトが追加され、必要に応じてさらにネストされます)
  • SpecificApplication
    • (任意の深いネストを持つすべてのタイプの DB オブジェクト)
  • など……。

明らかな欠点は、このフォルダー構造がデータベース オブジェクトにいかなる種類の名前空間階層も課さないことです。組織専用です。したがって、重複した名前を持つオブジェクトを導入するのは非常に簡単です。データベースプロジェクトを調査し、名前の競合で死ぬには、ある種のビルドツールが必要です。

私が知りたいのは、バージョン管理されたファイル構造でアプリケーションのサブジェクトごとに SQL ファイルを整理するこの方法を試した人はいますか? それは価値がありました？私が説明したように、プロジェクトを監視するビルド ツールを作成しましたか?

私はかなり大きなレガシーアプリケーションを維持しています。ソースツリーは本当に混乱しています。ビルドサーバーをセットアップしようとしています。

ソースツリーには、ソースを含むサードパーティコンポーネントがあります（プロジェクトのインクルードパスにもあります）。これらのコンポーネントもIDE内にインストールされます。

私の質問は：これらのコンポーネントを管理する方法は？

私はこのように管理しようと思いました：

• ビルドサーバーにIDEをインストールします
• すべてのサードパーティコンポーネントをインストールします
• プロジェクトソースツリーからコンポーネントソースを削除します（そして、それぞれが圧縮された専用フォルダーのプロジェクトルートに保持します）
• サードパーティコンポーネントをカスタマイズ（またはデバッグ）する必要があるたびに、パッケージを再ビルドし、ビルドサーバーのIDE（および各開発者ワークステーション）に再インストールします。

コンポーネントをIDEにインストールすることと、ソースをインクルードパスに含めることの違いは何ですか？リンカはその場合をどのように処理しますか？

何百ものプロジェクトがある場合、どのようにプロジェクトを整理しますか? プロジェクト内のレイアウトではなく、プロジェクトのルート ディレクトリのレイアウト。

私は、複数のシステムのディスク全体に散らばっている 10 年以上の個人プロジェクトとサンプル プロジェクトを統合しており、12 ほどのアクティブなプロジェクトを常に表示し、アーカイブされたプロジェクトを見つけられるようにするための整理方法を探しています。

ほとんどのプロジェクトは学習実験であり、さまざまな言語やフレームワークを横断しています。プロジェクトの中には、アイデアやコードを再利用するために手を差し伸べる本格的な実用的なアプリケーションもあります。

私は個人的なもののためにリモート git リポジトリでフラットな名前空間を使用していますが、それは私の開発システムで物事を整理する理想的な方法とは言えません。~/active/ や ~/archive/ よりも優れたものがあるはずです。

この状況で何がうまくいきますか？

問題の一部は、私が実際に質問が何であるかを知らないということであるため、これは幅広い質問かもしれません。私が知りたいのは、ページの配置（aspx）、ユーザーコントロール（ascx）、サーバーコントロール、その他のサポートクラス、ユーティリティ関数などの観点からASP.NETアプリケーションを一般的に整理する方法です。まず、既に存在すると仮定します。どこかにあるデータレイヤー（おそらく別のプロジェクト）。これは問題ではありません。私が頻繁に直面する問題は、複数のページを作成し、それらがいくつかの共通のレンダリングロジックまたはいくつかのユーティリティ関数、クラスなどを共有する必要があることに気付くことです。一部のユーザーコントロール）。これらのユーティリティクラス、共有クラス、ユーザーコントロール、サーバーコントロールなどを配置するのに最適な場所はどこですか？ここにいくつかの可能性があります。

組織を気にせず、すべての種類のファイルを並べて配置します。したがって、1つのディレクトリに、aspxファイル、一部のcsファイルなどがある場合があります。これはおそらく実際にはオプションではありません。

タイプ別にファイルを整理します。ユーザーコントロール用のディレクトリを作成し、そこにすべてのユーザーコントロールを配置するとします。OK、でもサーバーコントロールや他の通常のクラスはどうですか？それらも特別なディレクトリにあるべきですか？正しく聞こえません。これについて私が最も嫌うのは、機能（論理的に関連するコード）で作業するときは、あちこちでそれを探す必要があるということです。アプリケーションの機能と論理セクションも、何らかの方法でファイルシステムレベルでグループ化する必要があると思います。

私が欲しいのは、ページ（aspx）、ユーザーコントロール（ascx）、ハンドラー（ashx）を基本的にダミーのプレースホルダーとして、外部の訪問者の観点から論理的に整理されたディレクトリ構造に配置することです。実際のコード（ページ、ユーザーコントロールの実装、サーブコントロール、ユーティリティクラス）は、論理名前空間（アプリケーションのモジュールまたは機能によって編成された）に構造化された別のフォルダーに配置する必要があります。これを実現する唯一の方法は、<%@ Page ... %>ディレクティブを手動で操作することだと思います。

クレイジーに聞こえますか？質問しすぎですか？もっと良い方法はありますか？あなたのベストプラクティスは何ですか？あなたはいくつかの良い例を知っていますか？

編集：別のアイデア。これは、生成されたaspx、aspx.cs、およびaspx.designer.csファイルを台無しにすることはありません。私の当初の要件の1つは、aspxページを駆動するコードを自分の場所に配置し、それをカスタム名前空間階層に配置することでした。では、VSによって生成されたaspxクラスを単純にサブクラス化するとどうなりますか？MyAppというプロジェクトとその中にページがあるとしましょうMyPage.aspx。次に、VSはMyApp.MyPageから継承されたものを作成しSystem.Web.UI.Pageます。私はこのクラスをそのままにします（コードはそこに行きません）が、MyApp.SomeNamespace.SomeSubNamespace.MyPageから継承されたサブクラスを作成しMyApp.MyPageます。このようMyApp.SomeNamespace.SomeSubNamespace.MyPageにして、のサーバー制御に対応する自動生成された保護フィールドにアクセスできます。MyApp.MyPageそして、このページに関連するすべてのサポートクラスの「プライベート」名前空間全体を取得します。主な欠点はありますか？私を悩ませているもう1つの関連する問題は、この新しいcsファイルを物理的にどこに配置する必要があるかということです。Webプロジェクトには、App_Codeという標準のフォルダーがありますが、私はWebアプリケーションに興味があります。アプリケーションのルート（コードなど）にディレクトリを作成することは正しく聞こえません。

私が働いている会社は最近、今後のすべての開発作業に .NET と Java を組み合わせて使用​​することを決定しました。私たちは、コードを名前空間 (.NET) とパッケージ (Java) に整理する方法を標準化しようとしてきましたが、複数のプラットフォームを含む複数の製品の名前空間を整理しようとした経験はありません。

最近、Java フロントエンド (Blackberry デバイスで実行) と .NET バックエンド (Java フロントエンドが従来の VB6/COM コードと通信できるようにするメッセージ ブローカー) を使用する新製品に関与しました。 Java 側で COM を処理したい場合、既存の VB6 コードで .NET を簡単に動作させることができます)。現在、私は .NET 側に焦点を当てています。

という名前の新しい .NET ソリューションを作成しCompanyName.ProductName.Broker、最終的に 2 つのサブプロジェクトができましCoreた。ブローカー コードの大部分を実装するクラス ライブラリ プロジェクトと、BrokerConsoleブローカーをコマンドラインから開始および停止できるようにするコンソール プロジェクトです (ブローカーは実行されます)。サーバー上で RabbitMQ メッセージ キュー サーバーと一緒に)。

現在、両方のプロジェクトがCompanyName.ProductName.Broker名前空間のサブ名前空間にあります。問題は、これは理にかなっていますか?

一方では、BrokerConsoleプロジェクトはプロジェクトにかなり緊密に結合されていCoreますが、他方ではBrokerConsole、スタンドアロンの EXE にコンパイルされます。BrokerConsoleプロジェクトを別のルート名前空間に配置する方が理にかなっているのではないかと考えていました。CompanyName.Apps.ProductNameこれは、実際にはフロントエンドでCompanyName.ProductName.Broker.Core.dllあり、ライブラリではなくアプリケーションであるためです。

まったく新しいCompanyName.Appsルート名前空間を作成する理由は、通常、アプリケーションを作成するときに、参照しているライブラリとは別の名前空間に配置する (つまり、Web サーバー アプリケーションをSystem.Web名前空間に配置しない) ことです。参照されているライブラリがたまたま会社によって開発されたライブラリであることを除いて、私は同じ方向に沿って考えています。

これは良い考えですか、それとも「製品」(マーケティング用語で) に関連するすべてのものを共通のCompanyName.ProductName名前空間に保持するように努めるべきですか? 1 つの製品を構成する複数のプロジェクトを管理するためのより良い方法はありますか?

Java プロジェクトの標準的なディレクトリ レイアウトはありますか? どのレイアウトが一番好きですか?

プロジェクトのディレクトリ内の 'src' と 'bin' よりも複雑なレイアウトについて質問しています (つまり、テスト クラスやビルド構成などをどこに配置しますか?)。

前もって感謝します。

私はすでにiPhone用に2つのゲームを作成しました。最初のゲームはめちゃくちゃで、2番目のゲームはそれほど面倒ではありませんが、それでも完璧ではありません。

MVCを使用してゲームを作成するときに、クラス組織の優れたアドバイスを示すリンクが誰かにあるかどうか聞いてみたいですか？

複雑なRプロジェクトに着手すると、スクリプトがすぐに長くなり、混乱します。

私のコードが常に楽しく使えるようにするために採用できるいくつかのプラクティスは何ですか？私は次のようなことを考えています

• ソースファイルへの関数の配置
• 別のソースファイルに何かを分割するとき
• マスターファイルには何を含める必要がありますか
• 関数を組織単位として使用する（Rによってグローバル状態へのアクセスが困難になることを考えると、これが価値があるかどうか）
• インデント/改行の練習。
  • 扱う（{？
  • ）}のようなものを1行または2行に入れますか？

基本的に、大きなRスクリプトを整理するための経験則は何ですか？