组织我的代码的惯用方式

Question

我觉得悬而未决的“关闭的问题，太模糊，意见，......”但这里是。

如何组织我的 Go 代码库？

我有一个非平凡的应用程序（unix 守护程序），它与其他进程通信、读/写数据库、与 Web 服务器通信、具有内部状态。在 c++ 中，我会编写一堆类（可能在主要子组件的子目录中）。可以说这是项目

然后在更高级别上，我有与项目相关的实用 cli 函数。 projcli1, projcli2.... 我假设与一个项目相关的所有代码都在一个 GOPATH 下

如果我从事几个不相关的项目会怎样。我仍然使用一个 GOPATH 还是每个项目都有一个。

我试图找到示例代码库，但唯一的大集合是包存储库，那是一堆库 - 这并不是一回事。

如果这些问题太模糊，那该怎么办。同一个目录下的所有go文件都必须属于同一个包是正确的吗？

另一个简单的具体问题。我找到了一个很好的对象池实现。它的包装上写着“游泳池”——很好。我把它的单个文件放在哪里。在一个名为“pool”的子目录中，我想要一个名为 utils 的目录（或类似的东西）似乎我做不到。我的意思是我不能有 utils/pool 和 util/db（比如说）没有一个文件目录树

Answer 1

您的问题相当模糊，但您确实提出了一些可以回答的问题。

首先，如果您还没有阅读http://golang.org/doc/code.html，请阅读

你应该只需要一个 GOPATH；你可以有几个并在它们之间切换，但我想不出任何用例。

单个目录中的所有 go 文件必须用于同一个包，这是由编译器强制执行的。

在 Go 中组织大型项目时，最重要的是选择包并决定每个包中包含哪些代码。一些有用的提示：

• 包依赖不能是循环的 - 如果你的理论布局将有两个包相互依赖，那将不起作用
• 子目录是完全不同的包 - 它们与其父目录中的包没有特殊关系
• 每个包都应该独立有用 - 如果您必须导入包 b 才能使用包 a 中的东西，那么您的布局就会混乱
• 不要害怕相对较大的包 - 一开始在单个目录中有很多很多 go 文件很奇怪（在其他语言中您会使用子目录），但实际上并不会导致太多问题

对于您所说的那种规模的大型项目，我发现它们通常以三到四个包的形式结束：一两个实现理论上可以在其他项目中重用的独立核心组件，一个实现特定的作为一个库的应用程序功能，以及一个实现实际程序（守护程序，或用户界面，或你有什么）。当然，它总是取决于程序。