我一直在试验目录结构，目前正在使用下面的目录：
|
|_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存储Web应用程序，桌面存储桌面应用程序。 dev目录是版本控制的，而其他目录（prod，qe，uat）存储它们各自的当前版本。项目目录存储与代码无关的项目项。
您的软件开发目录结构是什么，是否有理由推荐该结构？
答案 0 :(得分：10)
我执行以下操作：
出于某种原因，将所有文件按项目分组保存并将我的非活动项目（我目前没有处理的项目）保存在另一个文件夹中对我有很大帮助。我想我会被他们分心。
答案 1 :(得分：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 :(得分：5)
我将所有内容存储在Windows机器上的“c：\ projects”目录中，以及我们的unix-oid（linux＆amp; solaris）环境中的〜/ projects中。下面我有一个“学习”（代码实验和片段/目录），然后是每个项目的一个目录。 一段时间后，当项目失效时，我擦除本地存储，代码仅在SVN中存档。
答案 3 :(得分：2)
src \＆lt; - 多个项目的源代码（下）
测试\
test_a＆lt; - 针对r＆amp; d的模块测试（使用src文件夹中的一些代码）
test_b＆lt; - r＆amp; d的b模块测试（使用src文件夹中的一些代码）
main_app_folder＆lt; - 用于制作的主项目文件（使用src文件夹中的大部分代码）
doc \＆lt; - Documents
工具\
tool_a＆lt; - 工具a（使用src文件夹中的一些代码）
tool_b＆lt; - 工具b（使用src文件夹中的一些代码）
cleanup.exe / .ini＆lt; - 用于清理临时构建文件的实用程序。
项目（在main_app_folder，测试或工具中）可以是.vcproj（visual studio c / c ++）,. mmp（Symbian makefile），Makefile（linux makefile）。每个项目都有自己的主.cpp文件 - 总是包含一组最小的功能，其他一切都或多或少可以重复使用（在src \文件夹中）。
测试应用程序和工具应用程序之间的区别在于工具显示或多或少有用的东西，而测试只检查它是否有效。
测试和主应用程序之间的区别在于测试应用程序不包含整个功能，测试应用程序也可能启用测试所需的一些特殊#define。通常测试应用程序是减少主应用程序集，而不需要额外的#define。
答案 4 :(得分：2)
我通常使用这个目录结构：
答案 5 :(得分：1)
我倾向于将所有项目分组到三个主目录中：
然后在这些文件夹中我有：
此外，每个项目都在git存储库中维护，其中包含一个描述它的doap文件（以及通常的内容，如README，INSTALL，NEWS，AUTHORS，LICENSE（通常是apache2），docs dir和srcs目录以及可选的libs目录和构建文件）。 如果连接了任何项目，那么doap文件会说明它（或者我只是为根项目创建一个文件夹并将所有相关项目放在其中）。 上面这两段的唯一例外是atic中的一些项目（其中一些是用Delphi 2编写的......）。
此外，只存储了源，因为我可以快速创建二进制文件。
PS：如果这让你想起你所知道的事情，那是因为我在apache软件基金会中鼓励自己来组织我的项目，所以我有实验室（或研究），atic，孵化器，doap文件等等。因为我这些天大多是一个java人，而且我想到了apache ......答案 6 :(得分：0)
我倾向于更喜欢更扁平的目录结构，并建议尽可能简单。请记住，至少在Windowsland中，命令行长度有限制。因此，具有非常深的结构可能会产生一些令人讨厌的构建错误。
答案 7 :(得分：0)
我只是为每个项目使用一个缺少名称的名称，并将所有相关文件和目录放入该目录中。像这样：
答案 8 :(得分：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
...