该文最早作为一次演讲发布于2018年欧盟 GopherCon。

背景

image.png

(不要盲目采信教条主义的建议，每次都应该对每条意见进行判断)

独一无二的JBD(不了解她，看 Twitter 的资料为 Google Cloud 工程师，有大量粉丝，译者注)给了我们非常专业的小建议（即上图）。当然，想必也包括她说的这条。但是我已经在本篇论述中进行了自我判断，并认为它是正确的。

image.png

（最近和一个朋友聊到写博客帖子和进行演讲是多么难。你在技术公司待时间长了，你总是最终会说，“这得依赖当时的情况”和“我不太确定”，但是这些不会让我写出一篇好博客，哈哈）
另外，网上有些人已经注意到一旦你在技术公司待得时间越长，你对一些技术的观点总是依赖于具体的情况和总是会说我不确定之类的。这同样适用于我。我的体验是如果你发现当你想在职业生涯上有所进步却固执己见时，你可能会陷入困境，成为一名专家级的初学者，这并不是好事。

无力？

总体来说，有两个关于别人给的建议会让我们陷入无力的困境中的真相：在某方面我越有经验，越不确定一些技术选型，因此我越少可能传递一些实战经验给你们，给观众。第二个是你越有经验处理别人的建议，越不太可能相信我给你们的建议。因此，我现在就应该结束这次演讲吗？我们应该立即散会吗？

---

为了摆脱这种无力感，我认为我们可以采用几个策略。首先，我们能确当我们给出建议时，我们处于一种让它起作用的一个特定的上下文环境中。如果我们定义了一个应用场景，我们就能有机会给出一个好建议。
这就是我试图在本次演讲中给大家提供的内容。我今天会在一个工业化场景下谈论编程。所谓的工业化场景为：

• 在一个初创或公司环境
• 在一个工程师流动频繁的环境
• 在一个代码比每个工程师都生命力持久的环境
• 在一个业务需求经常变化的环境

这就是我最近的职业生涯经历的环境，我有理由怀疑也同样适用于大家。在这种环境下对使用 Go 的最佳建议是不同于在个人项目或者大型开源工程库中的项目的。
为了不违背 JBD 的观点，我应该小心评判我给出的建议，因此你能跟从自己的内心，接受认为能说服自己的观点，得出自己的结论。我会尽力在本次演讲中做到这一点。
根据上述指导原则，让我们回顾下我要讲到的几个主题。我尽力选择那些会困惑新的和中级的 Gophers 的部分，因为曾经我也是新人，尤其是那些可能不明显和微妙的部分。

目录

1. 组织代码和仓库
2. 程序配置
3. 组件图
4. Goroutine 生命周期管理
5. 系统观测
6. 测试
7. 接口的数量选择
8. Context的使用选择

组织代码和仓库

我经常看到我的同事们，尤其是那些刚接触 Go 的人，总是想要有个严格代码结构，经常在项目开始就把它放在优先级较高的位置。我认为这通常会带来问题而不是帮助。为了理解为什么会这样，记住下面这句话，可能是工业级编程最重要的属性：

工业级编程...其业务需求经常变化

唯一的不变就是变化，业务需求唯一的规则就是它们从不收敛，它们只发散、成长和变化。因此我们应该确保代码在我们的生活之内，而不是不必要地框住了自己。我们的仓库、抽象和代码应该容易维护，所谓容易维护即容易改变、采用甚至删除。
这里有几个好的意见。如果你的项目有多个分发包，你可以把它们放在一个 cmd/ 子目录。如果你的项目比较庞大而且有很多 非 Go 代码，比如 UI 资产或复杂的构建工具集，你可以将你的 Go 代码单独放在 pkg/ 子目录。如果你有多个包，最好根据其业务域构建包，而不是根据实现场景，也就是说：user 包，很好； models 包，不好。

当然，业务域和实现并非严格分离。例如，大型WEB应用倾向于混合传输层和核心业务层。像 GoBuffalo 这样的框架鼓励使用像 actions, assets, models 和 templates 这样的包名。当你专门在处理 HTTP 的业务时，将他们耦合在一起或许是有好处的。

image.png

(作者：为包的内聚性而优化比为最小依赖原则而优化更有意义
Tim Hockin: 我的经验是，不作不死。你强制你的消费方引入并编译他们并不需要或不想要的代码。我猜如果生产者和消费者都是你自己，爱咋疯咋疯，否则这对第三方很不友好。
)

Tim Hockin 也建议我们对其包依赖边界LINK。(Tim Hockin, k8s、GKE 和 Google Cloud 主任软件工程师，个人认为其言论深切要点，建议点开查阅，译者注)也就是说，我们应该将包分离开来，例如 RedisStore, MySQLStore 等等，避免外部的消费方引入并编译它们不需要的包。个人认为包优化对于封闭引用并不合适，但是对于广泛应用的第三方包例如 Kubernetes 是很有意义的，在那种情况下，编译单元的大小很可能成为一个真实的瓶颈。
因此有几种应用场景。我认为最好的建议是在结构中缺省，一旦有需要，方才具体化。大部分我的项目开始时只需要几个文件，都放在仓库顶层的 main 包里，一直到有几千行代码仍然可以正常运行。我的许多甚至大部分项目也就这个规模。一个关于 Go 的好东西是它能让你感觉很轻量，我想要保持这种感觉。

程序配置