在本月初的 GopherCon 上，知名 Go 语言贡献者与布道师 Dave Cheney 发表了名为《The Zen of Go》的演讲，之后他整理了演讲内容在博客中分享，由于内容过长，他又写了一个简洁版本：
•
完整版：
https://dave.cheney.net/2020/02/23/the-zen-of-go
•
简洁版：
https://the-zen-of-go.netlify.com
这里简单翻译一下简洁版本的内容：
编写简单、可读、可维护的 Go 代码的十个工程要点。
每个包实现单一目标
设计良好的 Go 软件包提供一个单一的思路，以及一系列相关的行为。一个好的 Go 软件包首先需要选择一个好名字，使用电梯法则（30 秒内向客户讲清楚一个方案），仅用一个词来思考你的软件包要提供什么功能。
明确处理错误
健壮的程序其实是由处理故障案例的片段组成的，并且需要在故障出现之前处理好。冗余的if err != nil { return err }比出了故障再一个个去处理更有价值。panic 和 recover 也一样。
尽早 return，不要深陷
每次缩进时都会在程序员的堆栈中添加另一个先决条件，这会占用他们短期内存中的 7±2 个片段。避免需要深层缩进的控制流。与其深入嵌套，不如使用守卫子句将成功路径保持在左侧。
并发权留给调用者
让调用者选择是否要异步运行你的库或函数，不要强制他们使用异步。
在启动 goroutine 之前，要知道它什么时候会停止
goroutines 拥有资源、锁、变量与内存等，释放这些资源的可靠方法是停止 goroutine。
避免包级别的状态
要完成明确和减少耦合的操作，需要通过提供类型需要的依赖项作为该类型上的字段，而不是使用包变量。
简单很重要
简单不是老练的代名词。简单并不意味着粗糙，它意味着可读性和可维护性。如果可以选择，请遵循较简单的解决方案。
编写测试以确认包 API 的行为
软件包的 API 是与使用者的一份合约，不管先后，不管多少，一定要进行测试。测试是确定合约的保证。要确保测试使用者可以观察和依赖的行为。
如果你认为性能不行，先通过基准测试进行验证
以性能之名会犯下许多危害可维护性的������,��������罪行。优化会破坏抽象、暴露内部和紧密耦合。如果要付出这样的代价，请确保有充分理由这样做。
节制是一种美德
适度使用 goroutine、通道、锁、接口与嵌套。