保持包的简洁

包不要过大,保持包的简洁,有利于日后更好的修改或复用.

让一个包里的逻辑只针对当前的特定业务, 避免涉及多个场景.

创建包的时候,请遵循Unix哲学: Smaller things to build bigger things

---

存在关联的包应放到子目录

Go标准库使用是这种原则,例如:http 包, 它在 net package 内, 而 http 是又是具体一种网络协议, 所以把它放到 net 包里面,但并不意味着 http 包可以使用 net 包的相关方法.

Go 语言中的每个包都是不同的个体，因此 stdlib 中的 net 和 http 之间没有关系，只是为了组织代码结构而已。

---

把包创建为相关集群

尝试依赖同一组包内的东西,而不要依外部的包.

尽量把我们的包设计成相关的较小单元块.

---

隐藏内部的细节

仅公开外部需要的东西，并尝试隐藏该包内部的所有内容。

在我自己的项目中，所有特定于项目的私有代码都位于内部目录中。内部目录使我可以只将包中的内部信息隐藏到一组子包中. 我创建了一个* cmd *文件夹来作为程序的入口点命令，然后进行依赖项注入那里的其他业务流程代码。

---

依靠不常改变的事物

导入软件包时，请尝试依靠那些不会经常更改的软件包来巩固您的代码库.

导入软件包时，请使用您自己的代码作为可执行命令中的库.

假设您的代码是一个库，并设计其API尽可能可靠.

---

Go没有子包

当您想拆分软件包以组织BIG软件包时，可以使软件包的某些内部结构对外界可见，因此任何人都可以导入它们。您可能不想要这个

内部软件包约定可防止将软件包从不需要的一方导入。我将解释内部软件包在此后.

---

将测试放入同一目录

不要将测试代码放入单独的测试目录中.

将它们保持在一起，例如：* miner.go和miner_test.go *到同一目录中，他们幸福地生活在一起.

将测试所需的数据作为子目录放入testdata目录。 Go工具将遵守该约定.

miner/
miner.go
miner_test.go
testdata/
hashes.data
.

---

不要将代码放入./src文件夹

刚开始使用Go的gophers可以创建* src / *文件夹，而您无需这样做.

只需将源文件放入项目的根目录即可。这样更好.

也不要在内部包目录中使用* src文件夹.

---

将外部软件包放入供应商文件夹

我在自己的项目中使用* vendor 文件夹来锁定依赖项，而不是将其保存到 $ GOPATH *中以将特定版本锁定到特定项目.

---

Go中没有软件包版本控制和锁定

go get 始终从git存储库中获取存储库的HEAD的最新版本。但是，有一些解决方法.

您可以通过将所需软件包从其存储库中直接克隆到程序的供应商目录中来手动保存，以便使用和锁定所需的任何版本.

此外，您可以使用诸如 dep, glide, gpm, gopkg.in or other tools. 这些工具大多使用 semantic versioning 来获取并锁定软件包的版本.

更多技巧here.

---

不要从主出口

主软件包不是可导入的软件包，您无需从主软件包中导出内容。除非您要使用cgo之类的东西.

---

较小的程序可能不需要很多软件包

对于较小的程序，除了特殊软件包之外，您可能不需要定义其他软件包：main.

对于较大的程序，您可能需要定义自己的程序包来组织代码.

对于使用相同代码创建许多程序的人们，他们可能需要定义自己的库并将其导入到自己的程序中.

---

命名包

使用简单名称

像：* http，zip和时间。 *您和其他人将使用此名称并对其进行回忆。命名要简短，简洁，简洁.

请勿在名称中使用两个或多个单词

不是这样的：* net_http 。像这样操作： net / http 。不同的软件包，但是由于 http 软件包位于 net 目录中，因此如果存在另一个也称为 http的软件包，则*不会有问题，因为它们位于单独的目录中.

让包路径说明包的作用

• net / http 。很明显，不是吗？ * http * package是一个与网络有某种联系的软件包。如果在 security / http *软件包中，则意味着不同的含义.

不要重复包装名称

代替：miner.MinerInfo，使用：miner.Info。或者，代替：weather.WeatherTemperature，使用：weather.Temperature.

使用常用缩写

仅在程序员(或您正在构建的应用程序域中的程序员)熟悉的情况下。*。例如：stdlib使用fmt.

避免使用通用软件包名称

不是这样的：* api，模型，通用，utils，helper等*

例如：定义一个执行用户名为* user的用户操作的包，而不是模型包。 或者，将客户订单的另一个包裹定义为订单*.

请勿将所有内容放入模型文件夹中，而是将它们分成更小的包装。

但是，这在一定程度上是正确的。如果单独的软件包之间需要某种关系，则可以根据目标将它们聚在一起.

请勿使用下划线或骆驼装

只需使用小写字母.

注意：名称可以包含Unicode字符

*但是，我不建议您使用它. *

有关命名的更多信息：请查看here和here .

如果您在组织Go软件包方面有不同的经验，请在下面发送您的评论.

好了，现在就这些了.谢谢您到目前为止的阅读.

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

---

原文地址：https://blog.learngoprogramming.com/code...

译文地址：https://learnku.com/go/t/47098