23

私はディレクトリ構造を実験しており、現在以下のものを使用しています:

| |
 |_プロジェクト__
 | | | |
 | | |_blog.com_
 | | | | |_モックアップ
 | | | | |_ユーザー ストーリー
 | | | | |_....
 | | | |
 | | |_noteapp__
 | | |_モックアップ
 | | |_....
 | |
 |_webs______
 | | | |
 | | |_dev______
 | | | | |_blog.com_
 | | | | |_アプリ
 | | | | |_config
 | | | | |_....
 | | | |
 | | |_prod_____
 | | | | |_blog.com_
 | | | | |_アプリ
 | | | | |_....
 | | |_qe_....
 | | |_uat_....
 | |
 | |
 |_デスクトップ__
             | |
             |_dev______
             | | |_noteapp_
             | | |_アプリ
             | | |_config
             | | |_....
             | |
             |_prod...
             |_qe....
             |_uat....

                                                 鍵
                                                 開発 - 開発
                                                 製品 - 生産
                                                 qe - 品質工学
                                                 uat - ユーザー受け入れテスト

Web は Web アプリケーションを格納し、デスクトップはデスクトップ アプリケーションを格納します。dev ディレクトリはバージョン管理されており、他のディレクトリ (prod、qe、uat) にはそれぞれの最新リリースが保存されています。プロジェクト ディレクトリには、コードに関連しないプロジェクト アイテムが格納されます。

ソフトウェア開発のディレクトリ構造はどのようなものですか? また、その構造を推奨する理由はありますか?

4

9 に答える 9

10

私は次のことをします：

  • プロジェクト
    • プロジェクト1
      • 設計
      • ドキュメント
      • コード
    • プロジェクトn
      • 設計
      • ドキュメント
      • コード
    • 非活動中
      • プロジェクト1
        • 設計
        • ドキュメント
        • コード
      • プロジェクトn
        • 設計
        • ドキュメント
        • コード

何らかの理由で、すべてのファイルをプロジェクトごとにグループ化して、非アクティブなプロジェクト（現在作業していないプロジェクト）をさらに下のフォルダーに保持することは非常に役立ちます。そうでなければ、私は彼らに気を取られてしまうと思います。

于 2009-01-14T06:21:13.450 に答える
5

すべてをWindowsマシンの「c：\ projects」ディレクトリに保存し、unix-oid（linuxおよびsolaris）環境の〜/projectsに保存します。その下に「学習」（コード実験とスニペット/ディレクトリ用）があり、プロジェクトごとに1つのディレクトリがあります。しばらくして、プロジェクトが機能しなくなったときに、ローカルストレージを消去すると、コードはSVNにのみアーカイブされます。

于 2009-01-14T06:18:38.107 に答える
5

私はあなたのよりきめ細かい葉の大ファンですが、最上位レベルでは、ファイルシステムをプロジェクトごとに整理することで、はるかに優れたパフォーマンスを発揮します。私はコード ディレクトリにいて、「ねえ、これの仕様は何だったの?」と考える可能性がはるかに高くなります。spec ディレクトリに移動して、「どのプロジェクトの仕様が必要だったのか?」と考えるよりも、ダイアグラムを再配置するには:

|
|___webs____
|           |
|           |_blog.com_
|           |          |
|           |          |_docs_
|           |          |      |
|           |          |      |_mockups
|           |          |      |_user stories
|           |          |      |_...
|           |          |
|           |          |_code_
|           |          |      |
|           |          |      |_dev_
|           |          |      |     |
|           |          |      |     |_app
|           |          |      |     |_cfg
|           |          |      |     |_...
|           |          |      |
|           |          |      |_prod_ 
|           |          |      |_qa_
|           |          |      |_uat_
|           |
|           |_blah.com_
|           |          |
|           |          |_...
|
|_desktop___
|           |
|           |_noteapp__
|           |          |
|           |          |_...
|           |_...


                                                KEY
                                                dev  - development
                                                prod - production
                                                qe   - quality engineering
                                                uat  - user acceptance testing

とはいえ、私のオフィスの組織はあなたの方法に従っており、大規模な開発環境をサポートしているようです。個人的には、自分のプロジェクトが入っているディレクトリ以外のディレクトリでモックアップやその他のケースを検索しなければならないのは本当にもどかしいと思います (具体的には、アナリストとして、マーケティング モデルとは別の仕様を持っていますが、脱線します)。これらの概念を分離する委任の観点は、おそらくかなり理にかなっています。

ちょうど私の2セント。

于 2009-01-14T06:15:25.723 に答える
2

  • src\ <- 複数のプロジェクトのソース コード (以下)

  • テスト\

    • test_a <- r&d の a のモジュール テスト (src フォルダーのコードの一部を使用)

    • test_b <- r&d の b のモジュール テスト (src フォルダーのコードの一部を使用)

    • ...

  • main_app_folder <- 本番用のメイン プロジェクト ファイル (src フォルダーのほとんどのコードを使用)

  • doc\ <- ドキュメント

  • ツール\

    • tool_a <- tool a (src フォルダーのコードの一部を使用)

    • tool_b <- tool b (src フォルダーのコードの一部を使用)

  • cleanup.exe / .ini <- 一時ビルド ファイルをクリーンアップするためのユーティリティ。

プロジェクト (main_app_folder、テストまたはツール内) は、.vcproj (visual studio c/c++)、.mmp (Symbian makefile)、Makefile (linux makefile) にすることができます。各プロジェクトには、独自のメイン .cpp ファイルがあります。常に最小限の機能セットが含まれており、それ以外のすべては多かれ少なかれ再利用できる傾向があります (src\ フォルダー内)。

テスト アプリケーションとツール アプリケーションの違いは、ツールは多かれ少なかれ有用なものを表示するのに対し、テストは機能するかどうかのみをチェックすることです。

テスト アプリケーションとメイン アプリケーションの違いは、テスト アプリケーションにはすべての機能が含まれていないことです。また、テスト アプリケーションでは、テストに必要な特別な #define が有効になる場合があります。通常、テスト アプリケーションは、追加の #define なしでメイン アプリケーションのセットを減らします。

于 2009-04-21T07:28:34.577 に答える
2

私は通常、次のディレクトリ構造を使用します。

  • プロジェクト名
    • コード
      • ソース
      • テスト
      • 建てる
    • デザイン
    • 文書
    • ツール
于 2010-10-09T17:01:46.000 に答える
1

私はすべてのプロジェクトを 3 つの主要なディレクトリにグループ化する傾向があります。

  • ウェブデザイン => ウェブ関連のあらゆるもの。
  • プログラミング => Web に関係のないもの (ネットワーク機能がある場合でも)。
  • 研究 => それを行うために論文を読まなければならない場合。

次に、これらのフォルダー内に次のものがあります。

  • インキュベーター => 新しいプロジェクトまたは私が採用するプロジェクトの場合。
  • 退職（またはアティック）=>非アクティブなプロジェクトの場合。
  • 積極的に開発中のプロジェクトごとに n ディレクトリ。

また、各プロジェクトは、それを説明するdoapファイルとともに、gitリポジトリで維持されます（README、INSTALL、NEWS、AUTHORS、LICENSE（通常はapache2）、docsディレクトリ、srcsディレクトリ、およびオプションでlibsディレクトリなどの通常のものとともに）およびビルド ファイル)。プロジェクトが接続されている場合、doap ファイルはそれについて何かを示します (または、ルート プロジェクト用のフォルダーを作成し、関連するすべてのプロジェクトをそこに配置します)。上記の 2 つの段落の唯一の例外は、アティックのいくつかのプロジェクトです (そのうちのいくつかは Delphi 2 で書かれています...)。

また、ソースからバイナリをすばやく作成できるため、ソースのみが保存されます。

PS: これであなたが知っていることを思い出すなら、それは私が自分のプロジェクトを整理するために apache ソフトウェア ファウンデーションで自分自身にインスピレーションを与えたからです。ラボ (または研究)、アティック、インキュベーター、doap ファイルなどがあります。私は最近、主にJavaの男であり、Apacheが頭に浮かびました...

于 2012-06-02T00:24:07.200 に答える
0

svn 内のファイル:

SomeLibraryX
  SomeLibraryX.sln
  SomeFunctionA.cs
  SomeFunctionB.cs
  ..

SomeApplicationY
  SomeApplicationY.sln
  SomeApplicationY.cs          <-- might use SomeLibraryX as one of the dependencies

SomeApplicationZ
..

一部の共有 \\intra-pc\Releases\ 内のファイル

SomeApplicationY 1         <-- folder used to execute compiled binary. Contains all the necessary input files needed for execution.
  Model                    <-- all input files like xml:s and 3ds:s 
  Textures                 <-- all pictures 
  Depencies                <-- all dependency executables and dlls
  SomeApplicationY.exe     <-- main exe
  SomeApplicationY.ini     <-- execution parameters file, that can be drag&dropped onto main exe

SomeApplicationY 2
  Model 
  Textures
  Depencies
  SomeApplicationY.exe
  SomeApplicationY.ini

SomeApplicationY 3            <-- the last demo-release of this project that is currently under construction (used for executing and debugging the exe)

  Model 
  Textures
  Depencies
  SomeApplicationY.exe
  SomeApplicationY.ini

SomeApplicationZ 1
...
于 2009-04-19T16:15:58.477 に答える
0

私はよりフラットなディレクトリ構造を好む傾向があり、できるだけシンプルにすることをお勧めします。少なくとも Windowsland では、コマンド ラインの長さに制限があることに注意してください。したがって、非常に深い構造を持つと、厄介なビルド エラーが発生する可能性があります。

于 2009-01-14T06:56:45.050 に答える
0

各プロジェクトに短縮名を使用し、関連するすべてのファイルとディレクトリをその 1 つのディレクトリに放り込みます。このようなもの：

  • project_name (プロジェクト名、「省略形」)
    • dir1/ (実際にはこのような名前ではありません。)
    • dir2/
    • dirN/
    • ファイル1
    • ファイル2
    • ファイル3
    • ファイルN
于 2009-01-14T06:56:52.240 に答える