22

我一直在試驗目錄結構,我目前使用下面的一個:什麼是您的軟件開發目錄結構?

 
| 
|_projects__ 
|   | 
|   |_blog.com_ 
|   |   |_mockups 
|   |   |_user stories 
|   |   |_.... 
|   | 
|   |_noteapp__ 
|      |_mockups 
|      |_.... 
| 
|_webs______ 
|   | 
|   |_dev______ 
|   |   |_blog.com_ 
|   |      |_app 
|   |      |_config 
|   |      |_.... 
|   | 
|   |_prod_____ 
|   |   |_blog.com_ 
|   |      |_app 
|   |      |_.... 
|   |_qe_.... 
|   |_uat_.... 
| 
| 
|_desktops__ 
      | 
      |_dev______ 
      |   |_noteapp_ 
      |     |_app 
      |     |_config 
      |     |_.... 
      | 
      |_prod... 
      |_qe.... 
      |_uat.... 

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

站點商店的web應用程序,桌面商店的桌面應用程序。 dev目錄受版本控制,而其他目錄(prod,qe,uat)存儲其各自的當前版本。項目目錄存儲與代碼無關的項目項目。

什麼是您的軟件開發目錄結構,您有推薦該結構的原因嗎?

回答

5

我非常喜歡你的顆粒狀葉子,但是在頂層,我更好地執行了由項目組織的文件系統。我更有可能在代碼目錄中,想:「嘿,這是什麼規格?」比在規格目錄中,並且想:「我希望該規範適用於哪個項目?」要重新排列圖:

| 
|___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 

這就是說,在我的辦公室的組織遵循你的方法,並似乎支持一個相當大的開發環境。就我個人而言,如果不得不在除了我的項目之外的其他目錄(特別是作爲分析師,與營銷模型分開,但我離題)之外的目錄中搜索模型和其他案例,我感到非常沮喪,但是從流程 - 將這些概念分開的代表團立場可能具有很大的意義。

只是我的兩分錢。

+0

我通常也會用類似這樣的東西去做;這樣,老的/死的項目不會妨礙我,並在他們自己的「命名空間」中清楚地分離出來...... – reuben 2009-01-14 06:55:07

5

我將所有內容都存儲在Windows機器上的「c:\ projects」目錄中,以及我們的unix-oid環境中的〜/ projects目錄下。在下面,我有一個「學習」(代碼實驗和片段/目錄),然後爲每個項目一個目錄。 過了一段時間,當一個項目不存在時,我擦除本地存儲,代碼僅存檔在SVN中。

10

我做到以下幾點:

  • 項目
    • 項目1
      • 設計
      • 文檔
      • 代碼
    • 項目ñ
      • 設計
      • 文檔
      • 代碼
    • 不活躍
      • 項目1
        • 設計
        • 文檔
        • 代碼
      • 項目ñ
        • 設計
        • 文檔
        • 代碼

對於某些[R eason幫助我保留了按項目分組的所有文件,並且保留了我的非活動項目(我目前沒有工作的項目)在更下面的文件夾中。否則我會被他們分心。

+1

+1:我使用相同的結構(經過大量實驗) – 2009-07-24 00:00:27

0

我傾向於喜歡平坦的目錄結構,並希望建議儘可能簡單。請記住,至少在Windowsland中,命令行長度是有限制的。因此具有非常深的結構可能會產生一些令人討厭的構建錯誤。

0

我只是爲每個項目使用一個簡短的名字,並把所有相關的文件和目錄扔到那個目錄中。事情是這樣的:

  • PROJECT_NAME(項目名稱, 「缺兵少將」)
    • DIR1 /(未命名的這樣的現實。)
    • DIR2/
    • DIRN/
    • file1的
    • file2的
    • file3的
    • fileN
0

文件中的svn:

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

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

SomeApplicationZ 
.. 

文件中某些共享\\ PC內部\唱片集\

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 
... 
2
  • SRC \ < - 對多個項目(下文)

  • 測試源碼\

    • test_a < - 針對a的模塊測試& d(使用來自src文件夾的一些代碼)

    • test_b < - 模塊測試對於B的R & d(使用一些從src文件夾代碼)

    • ...
  • main_app_folder < - 生產(主要項目文件使用最規範的從src文件夾)

  • DOC \ < - 文件

  • 工具\

    • tool_a < - 工具(使用一些代碼的自src文件夾)

    • tool_b < - 工具B(使用了一些從src文件夾的代碼)

  • 清理。 exe/.ini < - 清理臨時構建文件的實用程序。

項目(在main_app_folder,測試或工具)能的.vcproj(視覺工作室C/C++),的.mmp(Symbian的生成文件),生成文件(Linux的生成文件)。每個項目都有它自己的主要.cpp文件 - 總是包含一小部分功能,其他所有內容往往會或多或少的重複使用(在src \文件夾中)。

測試應用程序和工具應用程序的區別在於該工具顯示的東西或多或少有用,而測試僅檢查其是否有效。

測試和主應用程序的區別在於,測試應用程序不包含整個功能,測試應用程序也可能啓用測試所需的一些特殊的#define。通常測試應用程序是減少主應用程序集,而不需要額外的#define。

2

我通常使用此目錄結構:

  • PROJ_NAME
    • 代碼
      • SRC
      • 測試
      • 構建
    • 設計
    • DOC
    • 工具
1

我傾向於組我的所有項目分爲三個主要的目錄:

  • 網頁設計=>對於任何相關網頁;
  • Programming =>對於任何與網絡無關的事物(即使它具有網絡功能);
  • 研究=>對於任何我必須閱讀論文才能做到的事情;

然後將這些文件夾中的我:

  • 孵化器=>對於新的項目或爲我採取項目;
  • 退休(或atic)=>對於不活動的項目;
  • 每個積極開發項目的n個目錄;

而且每個項目被保持在git倉庫,具有DOAP文件描述它(與通常的東西沿,如自述,安裝,NEWS,作者,LICENSE(通常apache2的),一個文檔目錄,和SRCS目錄和可選的庫文件目錄和生成文件)。 如果有任何項目連接,那麼doap文件會說明一些關於它的內容(或者我只是爲根項目創建一個文件夾並將其中的所有相關項目放入其中)。 上面這兩段的唯一例外是atic中的一些項目(其中一些用Delphi 2編寫......)。

此外,由於我可以快速創建二進制文件,因此只存儲源文件。 PS:如果這讓你想起你知道的事情,那是因爲我在Apache軟件基礎上啓發自己來組織我的項目,所以我有實驗室(或研究),atic,孵化器,doap文件等等。因爲我現在主要是一個java人,並且apache出現在我的腦海裏...

相關問題