你如何组织你的代码库？

Question

我很想知道人们如何组织他们的代码库，特别是在可重用组件方面。我正在以下面的OO术语进行讨论，但我对如何组织其他类型语言的库感兴趣。

例如：

• 您是否适合所有类课程项目，或者您是否希望将所有内容保存在单个项目中？
• 您是否重复使用预先构建的DLL，或者您是否在当前工作中包含以前项目中的各个类？如果是个别课程，您是否在项目之间分享这些课程以确保所有课程都保持最新或允许分支？
• 您的可重用元素有多大？他们有多关注？他们是如何关注的？
• 您通过首选做法获得了多大程度的重复使用？

等

修改

我不是在寻找具体的指导，我只是对人们的想法和实践感兴趣。我特别感兴趣的是在不同项目之间重用代码，而不是在单个项目中。 （不幸的是，在这里使用'项目'是误导性的 - 我的意思是在为客户而不是Visual Studio意义上的项目中进行的实际项目之间重用。）

Answer 1

通常可以通过部署注意事项进行指导：

您将如何部署（即您将在生产机器上复制什么）？

如果您正在部署的是打包组件（即dll，jar，war，...），那么将“代码库”组织为打包<的集合是明智的/ em>文件集。
这样，您将直接使用-dll，jar，war，...... - 将在生产平台上部署 这个想法是：如果它适用于那些打包的文件，它仍然可以在生产中使用。

---

  

在不同项目之间重用代码，而不是在单个项目中重用。

我认为在“组件”方法中更容易重用（如问题“Vendor Branches in GIT”中讨论的那种）

超过40个当前项目，我们实现了：

• 技术重用通过系统地将任何纯技术方面隔离到独立框架（通常是日志框架，异常框架，KPI - 关键绩效指标 - 框架等）。
  这些技术组件可以重复用于其他所有项目。
• 功能重用，通过设置清晰的 applicative 架构，将任何功能域（给定业务和功能规范）划分为定义良好的应用程序。例如，这通常涉及一个总线层，它也是暴露任何其他项目重用的服务的理想选择。

要点：
对于大型功能域，单个项目不可管理，良好的应用程序架构将导致自然代码重用。

Answer 2

我们遵循以下原则：

• 释放 - 重用等效原则：重复使用的颗粒是释放的颗粒。
• 公共关闭原则：应该针对相同类型的更改一起关闭包中的类。
• 通用重用原则：包中的类可以一起重用。
• 非循环依赖关系原则：在包依赖关系图中不允许循环。
• 稳定的依赖原则：取决于稳定的方向。
• 稳定的抽象原则：一个包应该是抽象的，因为它是稳定的。

您可以在here以及here上找到更多信息。

Answer 3

这取决于您工作的平台。我是一个（自豪的）Java开发人员，我们有很好的工具来组织我的依赖项，例如Maven或Ivy

Answer 4

无论你认为什么，良好的源代码控制对此至关重要，因为它允许你以任何你喜欢的方式实现你的策略，而不会结束你的库的大量无关副本。分支支持是必不可少的。