【译】Go语言编程模式【译】Go语言编程模式

声明：本文为InfoQ中文站特供稿件，首发地址为：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, })

【【译】Go语言编程模式】有意义的默认值：不要使用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还提出了”明确依赖关系“的建议，例如：

unc (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
本号专注于后端技术、JVM问题排查和优化、Java面试题、个人成长和自我管理等主题，为读者提供一线开发者的工作和成长经验，期待你能在这里有所收获。