不一样的go语言-gopher

前言

  gopher原意地鼠，在golang 的世界里解释为地道的go程序员。在其他语言的世界里也有PHPer，Pythonic的说法，反而Java是个例外。虽然也有Javaer之类的说法，但似乎并不被认可。而地道或者说道地，说的是gopher写的代码无不透露出go的独特气息，比如项目结构、命名方式、代码格式、编码风格、构建方式等等。用gopher的话说，用go编写代码就像是在画一幅中国山水画，成品美不胜收，心旷神怡。

环境变量

  gopher第一条：把东西放对地方。

  go程序的运行，需要依赖于两个基础的环境变量，GOROOT与GOPATH。环境变量几乎在各类编程语言中都存在，比如java的JAVA_HOME，其实也就是编译器及相关工具或标准库所在目录。但go除了GOROOT之外，还增加了GOPATH，它指的是go程序依赖的第三方库或自有库所在目录，以指示编译器从这些地方找到依赖。GOPATH支持多个目录，通常一个目录就是一个项目，并且GOPATH目录按约定由src、pkg、bin三个目录组成。gopher们的做法是定义Global GOPATH、Project GOPATH，而更大的项目还会定义Module GOPATH。当使用go get下载依赖时，会选择GOPATH环境变量中的第一个目录存放依赖包。

变量	含义	说明
GOROOT	go运行环境根目录	通常指go sdk安装目录，包含编译器、官方工具及标准库
GOPATH	工作环境目录列表	通常指第三方库、自有库及项目目录

GOPATH

1. src: 源代码目录
2. pkg: 编译时中间文件所在目录
3. bin: 编译后生成可执行文件所在目录

├── src
|   └── eventer.com
|       └── test
|           └── main.go
├── pkg
└── bin
|   └── test.bin

Global GOPATH

  全局GOPATH，通常将第三方库的代码保存至此处，便于所有项目引用，而不用重复下载。因此在GOPATH中，建议将global gopath放在最前面。

Project GOPATH

  如果项目比较简单的话，可以采用global GOPATH与project GOPATH的组合，即GOPATH设置为global GOPATH与project OGPATH两个目录。比如引用了需要对源码稍作修改的开源项目时，开源项目可以跟当前项目一起放在src目录下。

Module GOPATH

  在比较复杂的项目中，如果划分的模块比较多，则可以采用global, project, module三种GOPATH组合的方式，即即GOPATH设置为global GOPATH、project OGPATH、module GOPATH三个目录。

  最后请注意，global GOPATH、project GOPATH、module GOPATH不是go语言中的概念，go要求的只有GOPATH。而因为GOPATH是一个目录列表，所以我只是在实践中将GOPATH细分为上述三者，同时便于讲述GOPATH的概念。

项目结构

  gopher第二条：按东西放在约定的地方。

  不同复杂度的项目，大致可以有两种类型的项目结构，第一种是依赖较少、较简单的项目，如下图所示，其中mydriver项目是假设要引用的开源项目，但要在当前项目的使用中稍修改，因此与当前项目的源码放在一起。

├── src
|   ├── github.com
|       └── eventer
|           └── mydriver
|               └── driver.go
|   └── eventer.com
|       └── test
|           └── main.go
├── pkg
└── bin

  第二种是依赖较多、模块划分较细、较复杂的项目，如下图所示：

├── src
|   └── eventer.com
|           └── test
|               └── main.go
├── pkg
├── bin
├── module1
|   ├── src
|       └── eventer.com
|           └── lib
|               └── lib1.go
|   ├── pkg
|   └── bin
├── module2
|   ├── src
|       └── eventer.com
|           └── lib
|               └── lib2.go
|   ├── pkg
|   └── bin
└── module3
|   ├── src
|       └── eventer.com
|           └── lib
|               └── lib3.go
|   ├── pkg
|   └── bin

  其中的module1，module2，module3是基础模块，被主项目依赖。这个时候除了将主项目路径放在GOPATH外，还应当将基础模块路径放在GOPATH中。这样的项目结构不仅让项目清晰，还可以做不同的分工。

命名规范

  gopher第三条：把名字起得go一点。

  go语言的命名与其他语言最大的不同在于首字母的大小写。大写代表公开（导出，可以在其他包内访问）；小写代表私有（不导出，只能在包内访问）。除此之外，与其他语言并无二致，比如不能以数字开头。而由于关键字、保留字的减少，因而减少了一些命名上的忌讳。更为突出的是，go语言有一些建议性的命名规范，这也是gophers的圣经，理应严格遵守。

约定	范围	说明	示例
驼峰命名法	全局	统一使用驼峰命名法	var isLive = false
大小写一致	缩写短语，惯用词	如HTML，CSS, HTTP等	htmlEscape，HTMLEscape
简短命名法	局部变量	方法内、循环等使用的局部变量可以使用简短命名	比如for循环中的i，buf代表buffer等
参数命名法	函数参数、返回值、方法接收者	如果参数类型能说明含义，则参数名可以简短，否则应该采用有文档说明能力的命名	比如d Duration，t Time
通用命名法	作用域越大或者使用的地方离声明的地方太远，则应采用清晰有意义的命名	-
导出命名法	导出变量、函数、结构等	包名与导出名意义不要重复，同时包的命名要与导出的内容相关，不要使用宽泛的名字，如common，util	bytes.Buffer比bytes.ByteBuffer要好
文件命名	go文件，单元测试文件	go文件名尽量以一个单词来命名，多个单词使用下线划分隔，单元测试文件以对应go文件名加_test结尾	proto_test
包命名	包	包的一级名称应是顶级域名，二级名称则应是项目名称，项目名称单词间以-分隔	github.com/mysql

代码格式

  gopher第四条：按统一的格式来。

  在多人协作团队中，统一的代码格式化模板是第一要义。在Java语言中，检验新人经验的一大法宝就是他有没有主动索要代码模板。而在go语言中，则没有这个必要了。因为go已经有默认的代码格式化工具了，而且代码格式化在go语言中是强制规范。所以这使得所有go程序员写出来的代码格式都是一样的。

  go默认的代码格式化工具是gofmt。另外还有一个增强工具goimport，在gofmt的基础上增加了自动删除和引入依赖包。而行长则以不超过80个字符为佳，超过请主动以多行展示。

编码风格

  gopher第五条：请学会约定

项	约定	说明
import	按标准库、内部包、第三方包的顺序导入包	只引一个包时使用单行模式，否则使用多行模式
变量声明	如果连续声明多个变量，应放在一起	参见例子
错误处理	不要忽略每一个error，即使只是打一行日志	go的error处理方式与C同出一辙，通过返回值来标明错误或异常，引来的争议也很多，甚至官方已经开始酝酿在go2解决这个问题
长语句打印	使用格式化方式打印	-
注释规范	变量、方法、结构等的注释直接加上声明前，并且不要加空行。废弃方法加Deprecated:即可	其中的第一行注释会被godoc识别为简短介绍，第二行开始则被认为是注释详情。注释对godoc的生成至关重要，因此关于注释会有一些技巧，我将在后面用专门的章节探讨

多变量声明

var (
    name string
    age int
)

注释规范

// Add 两数相加
// 两个整数相加，并返回和。
func Add(n1, n2 int)int{
    return n1 + n2
}

依赖管理

  gopher第六条：使用依赖管理工具管理自有依赖与第三方依赖

  一个语言的生态是否完善甚至是否强大，除了github上面的开源项目数量之外，还有一大特征就是是否有优秀的依赖管理工具。依赖管理工具在业界已经是无处不在，yum、maven、gradle、pip、npm、cargo这些工具的大名如雷贯耳。那么go有什么呢？

  早期go的依赖是混乱的，因为没有一个工具能得到普遍认可，而官方又迟迟不出来解决问题。历数存在的工具包括godep、glide、govender等等。甚至早期还需要使用GOPATH来管理依赖，即项目的所有依赖都通过go get下载到指定的GOPATH中去。当然这种方案还可以撑大多数时间，但随着时间的流逝，随着开发人员的变动，这种管理依赖的弊端就慢慢显现出来。其实这些老路早期的java也走过，曾几何时，每个java项目里面都会有一个叫lib或libs的目录，这里放的就是当前项目依赖的包。当GO采用GOPATH来管理依赖时，开发人员只能被倒逼着用java的方式在源码库中自行管理依赖。这样相当于给依赖包做了隔离，同时又具备了版本管理（因为放在源码库）。

  后来在go1.5的时候，官方引入了vender的概念，其实这也没改变多少，只是官方让大家存放依赖包的目录名称不要乱起了，统一叫vender吧。这个方案我觉得比依赖GOPATH还糟糕，因为vendor目录脱离了版本管理，导致更换依赖包版本很困难，在当前项目对依赖包的版本更新可能会影响其他项目的使用（如果新版本的依赖包有较大变动的话），同时如何将依赖包放到vendor下呢？等等。当然官方做出的这些变动可能是想像maven那样，推动社区来完成这件事，因而直接推动了上文提到的基于vendor的依赖管理工具的诞生。直至后来官方默认的社区做出来dep，这下安静了，尽管刚开始时也不怎么好用，但有总比没有好。

  go1.11在vgo的基础上，官方推出了go module。在发布前，官方与社区的大神们还为此开吵，认为官方太不厚道且独断专行。完全忽视dep社区的存在，无视dep在go语言中的地位与贡献。喜欢八卦的朋友们，可搜索《关于Go Module的争吵》一览大神是怎么吵架的，也可从中学习他们的思想。

  作为dep与module的亲身实践者，还是乖乖地用dep吧。除非你有足够的热情去折腾，比如弄个高速的科学上网工具，或者搭建Go module proxy。开源的go module proxy比如athens，goproxy。《Hello，Go module proxy》一文详细介绍了go module的幸福与烦恼，反正我是没有感到幸福。此文很全面地介绍go module后遗症，goproxy可以解决科学上网的问题，然后也有了athens这样的工具出现，go的依赖管理是朝着越来越好的方向发展。dep与module的争议在于respect and free，至少目前看来，两者是可以共存的，特别是在国内。

  相对于java的依赖管理工具maven或gradle来说，gradle是maven的升级版，同时带来了DSL与元编程的特性，这无疑使得gradle异常地强大。但gradle.io在国内的可达情况也不尽如人意，好就好在其与maven仓库标准的兼容，使得从maven转到gradle几乎没有额外的成本及阻力。

  扯了这么多，依赖管理对于一门语言是必不可少的。c有cmake，java有maven、gradle，rust有cargo，那么go的dep或者module就用起来吧，看完大神吵架之后，喜欢哪个就选哪个。是不可能产生一个能满足所有人要求的依赖管理工具的，就连号称最牛逼的cargo也不例外。在一般的项目中，能用到的依赖管理功能也就那常用的几个而已，对大多数项目来说，适用好用就行。

构建方式

  gopher第七条：按需构建

  构建的目标是让代码成为可运行程序。构建的过程应该是低成本并且让人愉悦的，显然C在这一方面让人抓狂，而go确实做得不错。并且能在任何平台下编译出另外一个平台的可执行程序。不管你的go程序是CLI、GUI、WEB或者其他形式的网络通讯程序，在go的世界里都只需要一个命令构建成可执行程序（依赖也一并被打包），即可在目标系统上运行。在这一点上，java是望尘莫及了。

下面是用来构建go程序常用的参数，其他参数可通过go help environment命令查看。

参数	值	说明
CGO_ENABLED	0 or 1	是否支持cgo命令，如果go代码中有c代码，需要设置为1
GOOS	darwin, freebsd, linux, windows	可执行程序运行的目标操作系统
GOARCH	386, amd64, arm	可执行程序运行的目标操作系统架构

# Linux下编译Mac 64位可执行程序
CGO_ENABLED=0 GOOS=darwin GOARCH=amd64 go build main.go

# Linux下编译windows 64位可执行程序
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build main.go

# 如果想减少二进制程序的大小，可以加上-ldflags "-s -w"，但同时会丢掉调试信息，即不能用gdb调试了。
# 如果想更进一步减少程序大小，可以使用加壳工具，比如upx

请关注公众号