问题标签 [project-organization]

组织项目目录的一种流行方式或多或少是这样的：

app.cpp：

同一个库的所有.h和.cpp文件都在同一个目录中。为避免名称冲突，文件名通常以公司名称和/或库名称作为前缀。MyLib 将位于 MyApp 的头文件搜索路径等中。我不喜欢为文件名添加前缀，但我喜欢查看#include并确切知道该头文件所属位置的想法。我不讨厌这种组织文件的方法，但我认为应该有更好的方法。

由于我正在开始一个新项目，因此我想征求一些目录组织的想法。目前我喜欢这个目录结构：

app.cpp：

.cpp文件和私有（仅对直接库可见）.h文件存储在 src 目录下（src 有时称为 lib）。公共头文件被组织成一个 project/lib 目录结构，并通过<ProjectName/LibraryName/headerName.h>. 文件名没有任何前缀。如果我需要打包 MyLib 以供其他团队使用，我可以简单地更改我的 makefile 以复制适当的二进制文件和整个 include/ProjA 目录。

一旦文件被检入源代码控制并且人们开始处理它们，就很难更改目录结构。最好一开始就做好。

任何有组织这样的源代码经验的人？你有什么不喜欢的吗？如果你有更好的方法，我很想听听。

组织项目中文件的最佳方式是什么？

例如，您是将所有用户控件放在单独的文件夹中还是将它们放在子文件夹中？你有业务逻辑文件夹吗？助手类文件夹？

我曾经这样组织我的项目：

项目/用户控件/模块名称/项目/类/模块名称/

现在我正在学习更多类似的东西：项目/模块名称/用户控件/项目/模块名称/类/

什么是最好的方法？特别是如果项目变得非常大？应该存在什么类型的文件夹结构？

在我的公司，我们将每个数据库对象（存储过程、视图等）保存为单独的 SQL 文件，并以这种方式将它们置于源代码控制之下。

到目前为止，我们的版本化文件结构中有一个非常扁平的存储模型：

• DatabaseProject
  • Functions
    • （这里的所有功能；没有进一步的嵌套）
  • StoredProcedures
    • （所有存储的过程都在这里；没有进一步的嵌套）
  • Views
    • （同上）

对于一个大的新项目，我想到了另一个想法：为什么不按主题存储这些文件，而不是在这些预制平面列表中？

例如：

• DatabaseProject
  • Reports
    • （个人存储过程、视图等）
    • SpecificReport
      • （这里有更多对象，必要时进一步嵌套）
  • SpecificApplication
    • （所有类型的 DB 对象，任意深度嵌套）
  • 等等....

明显的缺陷是这种文件夹结构没有对数据库对象施加任何类型的命名空间层次结构。它仅用于组织。因此，很容易引入具有重复名称的对象。您需要某种构建工具来调查数据库项目并死于命名冲突。

我想知道的是：有没有人尝试过这种按应用程序主题在其版本化文件结构中组织 SQL 文件的方法？它值得吗？您是否创建了一个构建工具来监督我所描述的项目？

我正在维护一个相当大的遗留应用程序。源代码树真是一团糟。我正在尝试设置构建服务器。

在源代码树上，我有带有源代码的第三方组件（也在项目的包含路径中）。这些组件也安装在 IDE 中。

我的问题是：如何管理这些组件？

我想以这种方式管理：

• 在构建服务器上安装 IDE
• 安装所有第三方组件
• 从项目源树中删除组件源（并将它们保存在项目根目录中的每个压缩的专用文件夹中）
• 每次我们需要自定义（或调试）第三方组件时，我们都会重新构建包并将其重新安装在构建服务器的 IDE 中（以及每个开发人员工作站上）

在 IDE 中安装组件和在包含路径中安装源代码有什么区别？链接器如何处理这种情况？

当你有数百个项目时，你如何组织项目？不是项目内的布局，而是项目根目录的布局。

我正在整合十多年的个人项目和示例项目，这些项目分散在几个系统的磁盘上，并且正在寻找一些组织方法，让我保持十几个活跃的项目可见，并且可以找到存档的项目。

大多数项目都是学习实验，跨越一堆不同的语言和框架。其中一些项目是成熟的、可工作的应用程序，我可以利用这些应用程序来重用想法和代码。

我在远程 git 存储库中为我的个人资料使用平面命名空间，但这似乎不是在我的开发系统上组织事物的理想方式。肯定有比 ~/active/ 和 ~/archive/ 更好的东西。

在这种情况下什么对你有用？

这可能是一个广泛的问题，因为部分问题是我实际上不知道问题是什么。我想知道的是，您通常如何根据页面放置 (aspx)、用户控件 (ascx)、服务器控件和其他支持类和实用程序功能等来组织 ASP.NET 应用程序。首先，假设已经有某处的一些数据层（可能在不同的项目中）。这不是问题。我经常遇到的问题是创建几个页面并意识到它们需要共享一些通用的渲染逻辑或一些实用程序函数、类等。另一个典型的情况是某些页面变得太大以至于拆分它们看起来很方便（比如分成一些用户控件）。放置这些实用程序类、共享类、用户控件、服务器控件等的最佳位置是什么？这里有几种可能性。

不要真正关心任何组织，并将所有类型的文件放在一起。因此，在一个目录中，您可能有一个 aspx 文件、一些 cs 文件等。这可能不是一个真正的选择。

按类型组织文件。假设您为用户控件创建了一个目录并将所有用户控件放在那里。好的，但是服务器控件和其他常规类呢？它们也应该在特殊目录中吗？听起来不对。我最不喜欢的是，当你处理一个特性（逻辑相关的代码）时，你必须到处寻找它。我认为应用程序的功能和逻辑部分也应该以某种方式在文件系统级别上进行分组。

我想要的是将页面（aspx）、用户控件（ascx）和处理程序（ashx）基本上作为虚拟占位符，根据外部访问者的观点从逻辑上组织在目录结构中，而实际代码（页面、用户控件实现、服务控件和实用程序类）应放置在结构化为逻辑名称空间（由应用程序的模块或功能组织）的不同文件夹中。在我看来，实现这一目标的唯一方法是<%@ Page ... %>手动操作指令。

听起来很疯狂吗？我要求太多了吗？有没有更好的办法？你的最佳实践是什么？你知道一些好的例子吗？

编辑：另一个想法。这不会与生成的 aspx、aspx.cs 和 aspx.designer.cs 文件混淆。我最初的要求之一是我想将驱动 aspx 页面的代码放置到我自己的位置，并将其放置到自定义命名空间层次结构中。那么，如果我只是将 VS 生成的 aspx 类作为子类呢？假设我有一个名为 MyApp 的项目和其中的MyPage.aspx页面。VS 然后创建MyApp.MyPage继承自System.Web.UI.Page. 我留下这个类（没有代码会去那里），但创建一个子类，比如 in MyApp.SomeNamespace.SomeSubNamespace.MyPage，继承自MyApp.MyPage. 这种方式MyApp.SomeNamespace.SomeSubNamespace.MyPage将访问与服务器控件相对应的自动生成的受保护字段MyApp.MyPage我将为与此页面相关的所有支持类获得一个完整的“私有”命名空间。有什么大的缺点吗？另一个困扰我的相关问题是这个新的cs文件应该放在哪里？在 web 项目中，有一个名为 App_Code 的标准文件夹，但我对 web 应用程序感兴趣。在应用程序（例如 Code）的根目录中创建目录听起来不太对。

我工作的公司最近决定将 .NET 和 Java 结合用于所有未来的开发工作。我们一直在尝试标准化将代码组织到命名空间 (.NET) 和包 (Java) 中的方式，并且没有人真正有尝试为涉及多个平台的多个产品组织命名空间的经验。

最近，我参与了一个使用 Java 前端（在黑莓设备上运行）和 .NET 后端（允许 Java 前端与我们的旧版 VB6/COM 代码通信的消息代理）的新产品，因为我们没有想要在 Java 端处理 COM，并且很容易使 .NET 与我们现有的 VB6 代码一起工作）。现在我只关注.NET 方面的事情。

我创建了一个新的.NET 解决方案，CompanyName.ProductName.Broker名为与 RabbitMQ 消息队列服务器一起在服务器上）。CoreBrokerConsole

现在，这两个项目都在命名空间的子CompanyName.ProductName.Broker命名空间中。问题是，这有意义吗？

一方面，该BrokerConsole项目与项目非常紧密耦合Core，但另一方面，该项目BrokerConsole编译为独立的 EXE。我认为将项目放入单独的根命名空间可能更有意义BrokerConsole，可能类似于CompanyName.Apps.ProductName，因为它实际上是一个前端CompanyName.ProductName.Broker.Core.dll并且是一个应用程序而不是一个库。

我创建一个全新的CompanyName.Apps根命名空间的理由是，通常当您创建应用程序时，您将其放入与您所引用的库不同的命名空间中（即您不会将 Web 服务器应用程序放入System.Web命名空间中）。我的想法是一样的，只是引用的库恰好是公司开发的库。

这是一个好主意，还是我应该尝试将与“产品”（营销术语）相关的所有内容保存在一个公共CompanyName.ProductName命名空间下？是否有更好的方法来管理共同构成一个产品的多个项目？

Java 项目是否有任何标准的目录布局？你最喜欢哪种布局？

我问的是比项目目录中的“src”和“bin”更复杂的布局（即，您将测试类、构建配置等放在哪里？）。

提前致谢。

我已经为 iPhone 制作了两个游戏，第一个是一团糟，第二个不那么混乱，但仍然不完美。

我很想知道是否有人在使用 MVC 创建游戏时有一些指向良好的班级组织建议的链接？

当我承担任何复杂的 R 项目时，我的脚本很快就会变得冗长和混乱。

我可以采用哪些实践来使我的代码始终令人愉快地工作？我正在考虑类似的事情

• 在源文件中放置函数
• 何时将某些内容分解为另一个源文件
• 主文件中应该包含什么
• 使用函数作为组织单位（考虑到 R 使得访问全局状态变得困难，这是否值得）
• 缩进/换行实践。
  • 对待（像 {?
  • 将 )} 之类的内容放在 1 行或 2 行上？

基本上，您组织大型 R 脚本的经验法则是什么？