Go语言编程模式
在2016年伦敦举办的QCon大会上，Peter Bourgon做了 《六年Go语言设计经验》 的报告，重点探讨了在使用Go进行开发时的编程模式和反模式。在这里，我们将他给Go开发者的建议进行了简单的总结。
GOPATH：将 GOPATH/bin 添加到“PATH”这个环境变量中，以便Go应用可以访问所需要的二进制文件。在绝大多数场景下，Bourgon建议使用全局唯一的 GOPATH 。有些开发者希望严格区分自己的代码和外部依赖代码，这些人更倾向于创建两个 GOPATH 条目。开发者也可以选择不设置环境变量，并针对每个工程都使用 gb 构建。
代码仓库的结构：代码仓库的结构依赖于项目结构。如果是私人项目，开发者可以选择自己喜欢的任何结构。如果是开源项目，开发者最好遵循 Remote Packages 的建议，以便 go get 命令引用该项目的包。Bourgon建议创建一个基础目录，其中要包含程序的主要构件，以及放置帮助包的子目录，具体如下图所示：
代码格式化：Bourgon强调开发者需要重视Go的权威的代码格式化风格，一旦开发者习惯这种风格，他的代码的可读性将大大提高。按照Bougron的观点，Go开发者社区会认为非格式化的代码出自计算机新手。每次保存之前，可以使用 gofmt 工具格式化代码。他认为 Go代码审核指南 为开发者和代码审核者提供了一套通用的实践规则。他还支持 Andrew Gerrand关于Go开发的建议 ，包括如何为变量、函数和exports等元素命名，如果你能够遵循这些建议，阅读你代码的人将会非常感激你。
配置：Bourgon建议配置管理应该有“清晰的定义和良好的文档支持。”他仍旧在使用来自标准库的 flag 包，不过也希望这个包能够更简单易懂。他强调了明确定义配置项的重要性。通过环境变量传递配置项并没有为应用的使用者提供足够的信息去理解应用的参数使用，他建议在 help 中提供必要的配置信息。
包名：应该根据某个模块提供的服务而不是它的内容来定义包名。如果一个包含有 HelloWorld 消息，那么它不应该被称为 common 或 consts ，而是 greetings 。包名应该表明它所做什么，而不是它有什么。
点导入：Bourgon建议不要使用“点导入”，这个特性通过设置点号来代替包名，使得开发者不需要明确的包名就可以访问相应包中的变量。这个特性降低了项目的可读性，尤其对于新手，新来的开发人员容易弄错哪个变量属于哪个包。Go——显式声明优于隐式声明。
Flags：Bourgon并不认为在 init() 方法而不在 main() 方法中初始化flags是一个好主意，因为这使得这些flags无法在全局领域使用，而某些测试用例要用到这些flags。
构造函数：在谈到构造函数时，他建议将初始化的 struct 以内联方式直接作为参数传入，从而避免传入无效或者未完成的状态，例如：
foo := newFoo(*fooKey, fooConfig{ Bar: bar, Baz: baz, Period: 100 * time.Millisecond, }) 有意义的默认值：不要使用 nil 初始化某个变量，这使得每次在使用该变量的时候都需要进行空值检查，最好使用一个无操作值（no-operation value）进行变量初始化。例如，使用 ioutil.Discard 初始化一个 output 变量。
模块的交叉引用：有些情况下会出现两个互相引用的模块。在构建其中的一个时，同时需要构建另一个模块，在构建后一个时又需要第一个先构建，下列两个 structs 的定义就属于这种情况：
type bar struct { baz *baz } type baz struct { bar *bar } Bourgon提供了三种方法处理这种情况：
- 整合：两个关系如此密切的对象应该整合成一个，在这种情况下应该整合成一个 barbaz 结构体。
- 分割：如果这两个模块必须保持分割，那么可以应用下列代码中采取的策略：
type bar struct { a *atom monad } type baz struct { atom m *monad } a := &atom{...} m := newMonad(...) bar := newBar(a, m, ...) baz := newBaz(a, m, ...) - 通信：当上述两种方法都不适用时，可以考虑在两个模块之间发送消息。
type bar struct { toBaz chan<- event } type baz struct { fromBar <-chan event } c := make(chan event) bar := newBar(c, ...) baz := newBaz(c, ...) 依赖：Bourgon还提出了”明确依赖关系“的建议，例如：
func (f *foo) process() { log.Printf("bar: %v", result) // ... } 应该写成下面这样：
func (f *foo) process() { f.Logger.Printf("bar: %v", result) // ... } log.Printf 实际上调用了 Logger 模块，这么写的话就隐去了这层依赖关系。为了明确这层依赖关系，开发者应该在构造过程中创建一个 Logger 对象，并使用 ioutil.Discard 代替空值 nil 。
通道（Channel）：Bourgon建议，当多个协程（goroutine）之间共享内存时应使用mutex，并通过通道对协程进行协调。
日志打印：日志记录的代价很高，有可能成为应用的性能瓶颈。因此，建议只在绝对必要的地方记录日志，包括给开发者阅读或者供机器调用的信息。仅仅需要记录 info 和 debug 级别的日志。
监控工具：Bourgon认为Go应用的监控代价很小，推荐开发者使用 Prometheus 监控自己应用使用的各种资源。
全局状态：消除隐式的全局依赖和全局状态。
测试：执行包级别的测试。为了测试而设计：使用函数式编程风格——使用参数表明依赖关系、使用接口以及避免依赖全局状态。
依赖管理：将所有依赖项都拷贝到项目的仓库中用于构建二进制代码。Bourgon建议开发者根据自己的需要从 gvt 、 vendetta 、 glide 或 gb 这几个工具中选择。
构建：不要使用 go build ，要使用 go install ，因为后者可以缓存依赖关系，并把这些依赖关系放在 GOPATH/bin 下以便于调用。
这些建议已经被应用于开发 Go Kit ，一款用于构建微服务的分布式编程工具。
2009年以来，Bourgon在SoundCloud和Weaveworks两家公司都使用Go语言开发，开发了几款产品，包括： Roshi ——一款基于时间序列的事件数据库,以及Go Kit。
2016年QCon大会上的 《六年Go语言设计经验》 视频将会在今年晚些时候对外公开。
查看英文原文：Programming Patterns in Go
感谢邵思华对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号： InfoQChina ）关注我们。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
