我经常在与构建我的源代码树。实际上，通常，我不完成整个项目就不会倾倒整棵树并重新排列三到四次，这确实需要大量的精力，而且最终结果似乎是一个折衷方案。
有时候，我最终会过度分类源-文件夹和子文件夹的树很长。在其他时候，我只是根据所有文件的更大用途最终将所有文件集中在一个特定的文件夹中，从而导致源文件中的“混乱”文件夹。
我想问一下：
是否有任何原理/逻辑/最佳实践可以帮助我更好地构建源代码树？
是否有任何图形/图表技术（例如：DFD）数据流）可以帮助我基于项目分析预先可视化源树？
采用什么策略来构建与项目相关的多媒体文件树？
关于赏金：我很欣赏与成员分享自己的做法的现有答案，但是，我希望鼓励成员提供更一般性和指导性的答案（或资源），以及成员的更多答复。
#1 楼
源代码树布局应反映架构。因此，结构良好的体系结构可以导致结构良好的源代码树布局。我建议阅读POSA1层模式，尝试将您的体系结构调整为分层结构，然后命名每个结果层，并将其用作源层次结构的基础。以常见的三层体系结构为基准：presentation / webService（向我们的业务逻辑提供Web服务接口）
存储/ sql（此处为后端存储API-它使用SQL接口存储到数据库）
util / *（实用程序代码-可用于所有其他层，但不在util外引用，请转到此处）。请注意，这些层不直接包含代码，而是严格用于组织模块。
在模块中，我使用以下布局：
<module>（直接到模块的路径；定义模块化接口）<module>/impl/<implName>（模块化接口的特定实现）<module>/doc（使用模块的文档）<module>/tb（模块的单元测试代码）<module>在存储库中根据其所在的层位于何处它属于。评论
+1：源代码树的布局应反映出体系结构-这是我忽略的显而易见的事情。
–check123
2011年6月9日上午10:18
您如何管理安全文件-只有授权用户才能在登录后访问的文件？
–check123
2011年6月9日在10:23
@ check123我不确定我是否理解这个问题。我专注于源模块的组织，而不是为项目提供支持文件，并且源代码通常旨在供所有人使用。 （有例外，我在所有代码上方都使用dist /目录，但使用/修改的标准没有限制。）
–艾丹·库利（Aidan Cully）
2011年6月11日13:33
#2 楼
我真的不能给您很多与Web项目相关的建议，但是这是我在编程项目中构建树的方式（主要是从C / C ++的角度）：/
src —我自己编写的源文件
ext —包含第三方库
libname-1.2.8
标头
lib —编译的lib文件
Donwload.txt —包含下载所使用版本的链接
< br ide-我将项目文件存储在这里
bin -编译的exe文件在这里
build-编译器的构建文件
doc-任何类型的文档
自述文件
安装
复制
一些注意事项：
如果我正在编写库（并且正在使用C / C ++），那么我将组织我的库源文件首先放在两个名为“ include”和“ src”的文件夹中，然后按模块分类。如果它是一个应用程序，那么我将仅按模块组织它们（标题和源将放在同一文件夹中）。
我上面用斜体列出的文件和目录不会添加到代码存储库中。
评论
ide和build有什么区别？
–杜德利先生
2011年6月8日在16:44
ide就是我自己存储项目文件的地方。内部版本包含编译器生成的目标文件。不同的IDE可能使用相同的编译器，因此这就是我将IDE项目文件与由编译器生成的目标文件分开的原因。
– Paul
2011年6月8日17:48
因此，build == obj（许多其他系统使用的术语）
– gbjbaanb
2011年8月10日15:53
@gbjbaanb是的，我猜是。没关系，因为该目录不会被推送到存储库。 :)我称它为“ build”，因为那是我使用att称呼它的IDE（Visual Studio）。
– Paul
2011年8月10日17:33
如果您的exe需要一些dll才能运行该怎么办？是否将所有dll文件复制到与exe相同的目录中？是否使用了一些生成后事件？
–瓦坎坦卡
16-09-13在9:24
#3 楼
Maven标准目录布局是Java特有的，但它也可以作为其他类型项目的良好基础。这是基本结构（您可以将
java目录替换为php，cpp等）：src/main/java Application/Library sources
src/main/resources Application/Library resources
src/main/filters Resource filter files
src/main/assembly Assembly descriptors
src/main/config Configuration files
src/main/webapp Web application sources
src/test/java Test sources
src/test/resources Test resources
src/test/filters Test resource filter files
src/site Site
LICENSE.txt Project's license
NOTICE.txt Notices and attributions required by libraries
README.txt Project's readme
结构基本上分解为
src/main和src/test，然后按类型分组。#4 楼
理想情况下，组织具有单个存储库，该存储库的结构旨在增加工程与业务之间的互动并促进重用。...\products\
...\products\productName\
...\products\productName\doc\
...\systems\
...\systems\systemName\
...\systems\systemName\doc\
...\systems\systemName\res\
...\systems\systemName\build\
...\systems\systemName\test\
...\library\
...\library\libraryName\
...\library\libraryName\doc\
...\library\libraryName\build\
...\library\libraryName\test\
...\devops\
产品
每个产品一个文件夹；有助于传达软件如何支持业务。
理想情况下，每个“产品”仅是一个配置文件，该文件指示要调用的系统以及如何配置它们。
doc子文件夹可能包含顶级的摘要，规格和任何促销材料等。
通过分离产品和系统，我们将重用的潜力传达给了面向客户的业务部门，并细分了-产品筒仓。
（这与解决相同问题的“产品线”方法相反）
系统
每个系统一个文件夹；帮助传达存储库内容的主要功能和机会/价值。
“配置管理”文件指定了构建和部署环境。
系统级测试配置（可以
顶级逻辑和功能；
库
可重用的组件被各种系统调用。
大多数开发活动都是围绕库的生产而组织的系统，因此重用被“植入”开发过程中。
devops
构建，持续集成和其他开发自动化功能。
结论
源代码树是关键的文档，并通过其专有技术来塑造企业关系的方法，结构和心理。
这种方法的驱动因素是在我对这个问题的回答中有更深入的解释：https://softwareengineering.stackexchange.com/questions/43733/who-organizes-your-matlab-code/59637#59637
评论
注意：以与INCOSE系统工程手册中讨论的产品层次结构兼容的方式命名文件夹可能会很有用。
–威廉·佩恩（William Payne）
18年2月10日在21:07
#5 楼
我不太了解约定，但是我所有的主要项目都是使用Symfony Framework完成的，我已经习惯了如下所示的树形结构：root /
> apps
app_name
config（特定于应用程序的配置文件）
lib（特定于应用程序的php文件）
模块（功能的模块化分布）
module_name
模板（html）
动作（php代码）
confing（项目配置文件）
lib（可在钻孔项目中使用的php代码）
模型（代表项目信息的类）
base
表单（用于处理表单的php文件，如果没有symfony，这可能很难实现）
基本（基本表单类）
Web
css
图像
file.css
js
数据（特定数据信息，例如sql修补程序或其他内容）
插件（使用了tha的库可以与该项目的任何应用程序合并）
如果您有兴趣，请阅读有关此事的symfony文档以进一步查询（MVC和Symfony上的代码组织）。
评论
CSS文件夹集中了吗？我的意思是（整个项目中的）所有CSS都在同一目录中？
–check123
2011年6月9日10:21
不一定，您可以将其划分，但是由于我的大多数项目往往只有2个应用程序（前端和后端），因此css文件没有那么多（插件始终具有自己的用于抽象的Web文件夹）
– Guiman
2011年6月9日在10:40
#6 楼
我要为每个项目执行的操作类似于：src-源文件，每个命名空间/程序包的文件夹，可轻松检索文件（甚至是头文件）对于C / C ++）
ext-对于外部/第三方库，添加外部（例如SVN存储库）很简单。在内部，每个库（二进制文件和包含文件）的文件夹
bin-用于生成的二进制文件，可以快速导出以进行发布
inc-对于C / C ++头文件（由IDE / makefile / etc ...复制）
out-用于所有临时生成的文件（.class，.obj等...）和可以忽略它（例如，使用SVN）
doc-对于通常由Doxygen
res生成的任何文档-通过在此处放置资源，可以分离文本源文件以及程序使用的二进制资源。我真的没有特定的层次结构。
config-一些配置文件
drawable-一些图片或图标
如果仅使用其中之一，则所有IDE的文件或makefile都直接保存在根目录中。
#7 楼
我做这样的事情。对于我在业余时间从事的跨平台游戏来说效果很好。不幸的是，在工作中，事情变得井井有条...Output <-- Build outputs
Docs
External
<libname>
Include
Lib
Data
<ProjectName>.xcodeproj
<ProjectName>VS2010
Source
Temp <-- Intermediate stuff from builds and other tools
Tools
#8 楼
对于我的团队，我们尝试在项目之间强制执行标准结构，以便在团队切换上下文时易于查找内容，并避免每次都要重新学习。并非所有项目都需要所有系统，因此我们从最小的设置开始。/ Source / Component / Language
/ Source / Component / 3rd Party /
/ Documentation / Requirements
/文档/设计
/测试/自动化/单元
/测试/自动化/工具名称
/测试/手册
这会导致某些重复，尤其是在第三方代码和库，但至少我们永远不会忘记诸如“什么使用RogueWave编辑器？”之类的答案。
评论
大写的路径组件对我来说真的很愚蠢，毫无意义。为什么全部全部小写？对于人类来说，键入起来非常容易（尽管工具并不在乎，包括WIMP文件管理器），并且由于路径分隔符，其读取效果也同样好。最终赢得了我。
– ulidtko
15年1月16日在16:11
#9 楼
我喜欢此页面www.javapractices.com/topic/TopicAction.do?Id=205上提出的想法。基本上，建议将项目组织成功能（或模块，组件）。除了此处介绍的原因外，考虑到正在处理的代码范围时，认知负担也较小，因为可以保证功能中的任何代码都在起作用当您保证只为给定功能修改代码时，就会增加一种安全感。例如，除了您正在使用的功能外，您不会破坏其他任何功能。同样，这是由于“功能性-私有”。
认知负荷较低，因为对于给定的软件包，您可以看到的文件更少。我敢肯定，每个人都看过一个包含15个以上文件的包。请注意，这是针对Java包（即名称空间）的。对于大型项目，出于相同的原因，我建议将项目分为代表业务功能的多个项目（如在多个Maven项目中）。对于Maven项目，我建议阅读以下内容。
到目前为止，我所参与的项目并未遵循这些。原因有很多，但有几个原因：
对Java默认访问修饰符的误解（根据本书，大多数误解了访问修饰符）
“ Argumentum ad populum”：普遍存在逐层打包的文化（可能是由原因1引起的）
如果在项目开始时没有认真考虑项目源组织，我认为有一个错失机会来防止复杂性亚历山大说：
“正如任何设计师都会告诉你的那样，这是设计过程中的第一步，而这是最重要的。前几招创造了
，将其余的命运带入其中。” -Christopher
亚历山大
根据项目的规模和复杂性，错失的削减成本或ROI的机会可能会很大。 （我有兴趣查看一项研究以了解确切数字）
#10 楼
我的建议是下载各种框架或引擎，并查看庞大的开发团队如何处理其文件夹布局。组织文件的方法太多了，最好选择一种方法并坚持使用在任何给定的项目。请遵守特定的约定，直到完成或改版，以避免错误和不必要的时间。
您可以下载适用于Web项目的Laravel，Symphony或Codeigniter框架，以使即时文件夹布局有效。
因此，我将尝试传达任何开发通用的文件夹布局：
MVC（模型视图控制器）提供了良好的组织范例。
根源代码可能是src（C ++）或应用程序（Web开发）
一个文件结构，对于它所分组的类没有明确的目标，这肯定会引起混乱。它不仅可以组织代码，而且可以维持自动加载程序，类工厂，包装本地存储，远程存储和命名空间。
此文件夹结构是从Laravel Framework派生并简化的。我在这篇文章中的偏好是复数命名，但是我在项目中使用单数词。
src / storage（models / file-storage / api / mysql / sql-lite / memcached / redis实现）
src / repository（“存储实现”的包装，带有一些存储逻辑，公共接口和返回结果约定。）
src / services |逻辑|实体（应用程序业务逻辑）
src / controllers（用于Web开发，将服务器请求路由到您的服务）
src / modules |系统（扩展框架常规功能的模块化系统。服务可以使用模块，反之则不能使用）
src / helpers（Helper或wrapper类，例如字符串操作。很多时候可以在libs | vendor上使用）当第三方时）
src / types（命名枚举）
public |建立输出（Web或C ++）
config（设置文件。YAML在跨平台配置文件中变得越来越流行）
缓存
日志
lang（zh / es / ru / ...）
bootstrap（启动框架和应用程序）
docs（以markdown格式.md编写的文档）
测试（单元测试） ）
数据库/迁移（从头开始创建数据库结构）
数据库/种子（使用虚拟数据填充数据库以进行测试）
库|供应商（所有第三方软件。C++上的“ libs”和php上的“ vendor”）
资产|资源（图像/声音/脚本/ json /任何媒体）
#11 楼
使用面向对象的语言，您可以构建名称空间。用于分离应用程序的各个部分以避免耦合的逻辑故障是逻辑文件位置故障的主要来源。使用耦合作为打破命名空间的原因是开始http://en.wikipedia.org/wiki/Software_package_metrics的好地方。其他人谈到了建立与构建相关的项目，但是一旦您进入源代码本身，便是有意义的-只是使用您如何在逻辑上分解代码即可。
评论
我现在没有时间写论文，而是“以事物的名称命名”，“将事物放在它们所属于的地方”，“保持相似的事物彼此靠近”，最后，“不必担心” ，希望您有一个IDE可以帮助您在代码片段之间快速导航。”@John，我对IDE不太满意，根据操作系统，我通常会拉出Notepad ++或vi。这使事情变得更加困难。其余各点很有帮助，但又归结为做出棘手的决定，例如更接近应用程序逻辑或DAL或缓存管理或视图管理器的日志（错误日志等）功能。错误在任何一个错误中发生的可能性几乎相等。
也许一旦您提出了这样的问题，就该让一些工具为您完成一些工作了。日志记录显然是跨功能的问题，已被应用程序的所有部分所使用（如果您使用的是需要记录日志的代码）。另一句话是“将代码置于使用它的代码之上”，因此日志记录应该放在顶部，也许在\ utilities中。
@约翰：非常感谢。也许我应该开始寻找IDE。 Eclipse似乎很有前途。
@ check123“……将零件重新排列三到四次……”常见做法：“因此，管理问题不是是否要建立试验系统并将其丢弃。你会做到的。唯一的问题是是否要事先计划以建立一次性产品，或承诺将一次性产品交付给客户。” ―小弗雷德里克·布鲁克斯（Frederick P. Brooks Jr.），《神话般的月刊：软件工程随笔》