Laz*_*Laz 23 language-agnostic directory-structure project-structure
我一直在试验目录结构,目前正在使用下面的目录:
|
|_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)存储它们各自的当前版本.项目目录存储与代码无关的项目项.
您的软件开发目录结构是什么,是否有理由推荐该结构？
Dav*_*vid 10
我做以下事情:
出于某种原因,保留所有按项目分组的文件对我有很大帮助,并将我的非活动项目(我目前没有工作的项目)保存在另一个文件夹中.我想我会被他们分心.
我是你更细粒度的叶子的忠实粉丝,但是在顶层我通过项目组织的文件系统表现得更好.我更有可能在代码目录中思考,"嘿,这是什么规格？" 而不是在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
也就是说,我办公室的组织遵循您的方法,似乎支持一个大的开发环境.就个人而言,我发现在我的项目所在的目录中搜索模型和其他案例真的很令人沮丧(具体来说,作为分析师,规范与营销模型分开,但我离题了),但是从一个过程 - 将这些概念分开的委托立场可能很有意义.
只是我的两分钱.
我将所有内容存储在我的Windows机器上的"c:\ projects"目录中以及我们的unix-oid(linux和solaris)环境中的〜/ projects中.下面我有一个"学习"(代码实验和片段/目录),然后是每个项目的一个目录.一段时间后,当项目失效时,我擦除本地存储,代码仅在SVN中存档.