背景🐋
这是我学习golang的第三天,大致已经掌握了golang的语法,但是着手开发的时候,却遇到了许多问题,例如golang导包机制、golang的项目管理规范、go mod生成project怎么管理依赖的等等。其实这些概念之前也了解过,但是也只是如蜻蜓点水般的了解。正好,现在遇到了这些问题,那便认真总结一番。
问题总结
一个优秀的Go项目的布局是怎样的?😎
这个我在网上搜了很多的资料,不管是博客还是视频,他们大部分教的是在Go ENV路径下创建你的project,然后cd到你的project,接着在该项目文件夹下创建bin、src 和pkg目录。目录布局大致如下:
.
├── bin
├── pkg
├── src
│ ├── github.com
│ │ ├── user
│ │ │ └── project1
│ │ └── user
│ │ └── project2
│ ├── main.go
│ └── other.go
├── vendor
├── Makefile
└── README.md
bin
目录放置编译生成的可执行文件。pkg
目录放置编译生成的包文件。src
目录是源码目录,它包含了项目的所有Go源代码,外部依赖库的源代码也可以放在该目录下。vendor
目录存储了第三方依赖库的代码,类似于其他语言中的node_modules
目录或pip
的virtualenv
机制。Makefile
包含了项目的构建与管理规则,如编译、测试、部署等。README.md
文件包含了项目的说明文档和使用说明。
这种目录布局其实还挺清晰的,但是自从go引入go modules做依赖管理,项目布局结构会变得更精简,更灵活。具体目录布局如下所示:
.
├── cmd
│ └── main.go
├── internal
├── pkg
├── vendor
├── go.mod
└── README.md
cmd
目录是程序的入口代码,即main
函数的实现。internal
目录用于存放应用程序的私有代码,不能被其他项目引用。pkg
目录用于存放应用程序的公共库代码,可以被其他项目引用。vendor
目录用于存放依赖库的代码,类似于其他语言中的node_modules
目录或pip
的virtualenv
机制。go.mod
是 Go modules 的配置文件,用于管理依赖关系和版本控制。README.md
文件包含了项目的说明文档和使用说明。
当然根据业务要求,我们还可以添加docs目录存放项目文档,添加test目录存放单元测试代码。
Tonybai大佬的图画的相当不错,我这边引用一下,大家看完图就知道一个Go语言的经典布局该是什么样的了。
ps:图有点糊,将就一下......
项目结构目录重点突出一个清晰明了,我们需要清楚每个目录代表的含义是什么,每个目录下的文件有哪些,目录文件的调用关系,目录文件的隐蔽性等等。
为什么一定是go mod?🤔
我提出这个问题并不是吹毛求疵,而是真心想了解在没go module管理时,大家不也写的好好的么,为什么go module出来后,大家会立马抛弃以前的做法。这 go module到底带来了什么好处,如此吸引人。
我还是从项目布局上理解,在没有go module管理时,大家的项目布局应该长这样:
.
├── bin
├── pkg
├── src
│ ├── github.com
│ │ ├── user
│ │ │ └── project1
│ │ └── user
│ │ └── project2
│ ├── main.go
│ └── other.go
├── vendor
├── Makefile
└── README.md
首先在 Go 1.11 版本之前,如果要在 $GOPATH
中运行一个项目,该项目必须存放在 $GOPATH/src
目录下。布局里就包含了project1和project2两个项目文件目录。这会导致你的src目录越来越肿大。
其次是手动管理依赖问题。在Go 1.11版本之前,Go 语言没有官方的依赖管理工具,因此在项目中引入外部依赖库的时候,通常需要手动将依赖库的代码拷贝到 $GOPATH/src
目录下。这个光不是手动下载的事,你还要考虑到手动更新,依赖之间的冲突问题,部署的问题等等。在倡导DEVOPS的时代,哪一个都是让人分心头痛的事😣。
然而,go module解决了上述问题(怪不得大家会极力拥抱这门新技术)。这里举个例子说明两者的差别,让思路更清晰。
假设有两个项目 A 和项目 B,都依赖于 Go 语言的一个第三方库 github.com/gin-gonic/gin
。其中,项目 A 使用传统的依赖管理方式,项目 B 使用 Go modules 来管理依赖。
一、使用传统的依赖管理方式的项目 A:
项目 A 的目录结构如下:
.
├── main.go
└── vendor
└── github.com
└── gin-gonic
└── gin
├── LICENSE
├── README.md
├── bindings
├── contributing.md
├── favicon.ico
├── gin.go
├── go.mod
├── go.sum
├── handlers
├── logger.go
├── middleware.go
├── render
├── router.go
└── vendor
main.go
文件中引入了 github.com/gin-gonic/gin
:
package main
import (
"github.com/gin-gonic/gin"
)
func main() {
r := gin.Default()
// ...
}
在项目 A 中,依赖库 github.com/gin-gonic/gin
的代码被存放在 vendor
目录中,无法和其他项目共享使用。需要说明地是,使用 vendor
目录来管理依赖库是 Go 语言在 Go 1.5 版本时引入的方式。在使用 vendor
目录管理依赖库的时候,你需要将依赖库的代码复制到项目目录下的 vendor
目录下,然后在代码中引用这些依赖库。如果这个依赖库的版本发生升级,需要手动更新并重新拷贝代码到 vendor
目录,容易出现版本冲突或遗漏问题。
二、使用 Go modules 的项目 B:
项目 B 的目录结构如下:
.
├── go.mod
├── main.go
└── vendor
main.go
文件中同样引入了 github.com/gin-gonic/gin
:
package main
import (
"github.com/gin-gonic/gin"
)
func main() {
r := gin.Default()
// ...
}
在项目 B 中,使用 go mod
命令来管理依赖库和版本,无需手动拷贝依赖库代码。执行以下命令会自动下载依赖库代码至 $GOPATH/pkg/mod
目录下:
go mod init example.com/B
go mod tidy
安装完依赖库后,可以把 $GOPATH/pkg/mod
目录下的 github.com/gin-gonic/gin
目录拷贝到其他项目中使用,从而实现依赖共享。如果需要升级或切换依赖库的版本,只需要修改 go.mod
文件中的版本号即可,不会影响到其他项目。
这里可能有一个歧义的点,就是“拷贝到其它项目中使用”这个说法。依我看,go mod会自动安装你所需要库的依赖,它会在本地留下缓存信息。那么如果另一个项目中也需要使用 github.com/gin-gonic/gin
,可以直接在代码中引用该依赖库,如下所示:
package main
import (
"github.com/gin-gonic/gin"
)
func main() {
r := gin.Default()
// ...
}
只要之前已经在任意一个项目中使用了 go mod
命令下载过并缓存了 github.com/gin-gonic/gin
,Go 会自动从缓存中加载依赖库代码,而不会重新下载依赖库代码到 $GOPATH/pkg/mod
目录下。
这种方式可以实现依赖库的共享,避免了多个项目同时拷贝依赖库代码,节省了磁盘空间。同时,如果需要使用不同的版本号,可以通过修改 go.mod
文件来实现对特定版本的依赖管理。
当你修改了 go.mod
文件中的依赖版本号或者添加了新的依赖项之后,可以使用 go mod tidy
命令来更新依赖关系,例如:
# 修改 go.mod 文件中的依赖版本号
go mod edit -require github.com/gin-gonic/gin@v1.7.2
# 更新依赖关系
go mod tidy
go mod tidy
会根据 go.mod
文件中的依赖关系自动下载并更新依赖库代码,以保持依赖关系的一致性,并且会删除未被引用的依赖项。
另外,如果你还希望移除某一个不再使用的依赖库,可以使用 go mod tidy -v
命令,它会输出垃圾收集的详细信息,包括哪些依赖项是被移除的。
Go的导包机制是什么?✌️
我的人生信条就是优雅,如何优雅地导包也是我所追求的。
在了解怎么导包之前,我们先需要了解包在Go里面的具象化的体现是什么?包和模块的区别是什么?
抛开语言,从软件角度考虑,我们认为子程序的集合称为包,包的集合称为模块,模块的集合称为子系统,子系统的集合称为系统。将这个说法往Go语言上代入,能发现我们编写的go文件就是子程序,go文件所在文件夹就是包,根目录的文件名就是模块名。这些具象化的体现还能从哪里看出来呢?其实还能从我们创建的文件中看出。
以这样的目录结构为例:
project/
|- go.mod
|- main.go
|- controllers/
|- user.go
|- admin.go
其中:
go.mod
是模块文件,位于项目根目录。main.go
是入口文件,位于项目根目录。controllers/
目录下有两个文件user.go
和admin.go
一般来说,当你查看go.mod文件时,能看到第一行写着
module project
这是告诉你模块名是project。如果以后你的代码开源了,别人想引用你的代码,首先就是要根据你的模块名再找对应的包名。这和其它语言引包的方式很相似。
module后面的模块名是允许修改的,你可以换成自定义的写法,通常的写法是域名+项目名
。
再打开user.go,你能发现第一行写着
package controllers
这是指user.go是controllers包下面的一个子程序。
理清楚这些概念,我们还需要记住一个总纲:“导包其实就是寻址!导包其实就是寻址!导包其实就是寻址!”。重要的话说三遍!
还是以上面的目录结构为例,如果需要在 main.go
中导入 controllers/user.go
文件中的代码,可以使用相对路径 ./controllers
来导入 user.go
文件。
// main.go
package main
import "./controllers"
func main() {
// ...
}
对于模块,可以使用模块路径来引用相对路径下的文件。例如,假设你的模块路径为 example.com/mymodule
,则可以在 main.go
中使用 example.com/mymodule/controllers
来引用相对路径下的 user.go
文件。
// main.go
package main
import "example.com/mymodule/controllers"
func main() {
// ...
}
需要注意的是,使用相对路径导入包时,包的实际路径是相对于当前文件所在的目录。如果在其他文件中也要使用相对路径导入 controllers/user.go
,则需要将路径设置为相对于这个文件的路径。同时,相对路径只适用于模块内的代码,如果要在不同的模块之间导入代码,必须使用完整的包路径。
Go的测试代码怎么生成?👀
在 Go 中,我们可以通过创建测试文件来编写测试代码。测试文件应该遵循 Go 的命名规则,即在文件名后面加上 _test
。例如,如果要编写一个名为 sum
的函数的测试代码,那么测试文件的文件名应该是 sum_test.go
,而被测试的函数前面要加个Test前缀。
在测试文件中,我们可以使用 testing
包提供的一系列函数来编写测试代码,例如 testing.T
的 Error
、Fail
和 Fatal
函数,以及 testing.B
的 ReportAllocs
、ResetTimer
和 StopTimer
等函数。
下面是一个简单的测试示例,测试 sum
函数:
// sum_test.go
package main
import "testing"
func TestSum(t *testing.T) {
tables := []struct {
a, b, expected int
}{
{1, 1, 2},
{2, 2, 4},
{3, 3, 6},
}
for _, table := range tables {
result := sum(table.a, table.b)
if result != table.expected {
t.Errorf("Sum of %d + %d was incorrect, expected %d but received %d", table.a, table.b, table.expected, result)
}
}
}
在这个测试文件中,我们首先导入 testing
包,并定义了一个名为 TestSum
的测试函数。tables
定义了一个结构体切片,其中包含了一组要测试的参数和期望结果。我们遍历 tables
切片,逐一测试每组数据,判断计算结果是否和期望的结果一致。如果不一致,我们使用 t.Errorf
函数输出错误信息。这样就完成了一个简单的测试文件。
要运行测试文件,可以在项目根目录下使用 go test
命令运行。Go 会自动查找并运行所有的测试文件,并输出测试结果。测试结果中会显示测试用例的数量、测试是否通过以及每个测试用例的具体信息。例如:
$ go test
PASS
ok project 0.008s
在本示例中,我们只有一个测试用例,测试结果判定为 “ PASS ”,表示测试通过了。如果测试失败,则测试结果会判定为 “ FAIL ”,并输出具体的错误信息。
参考资料
https://tonybai.com/2022/04/28/the-standard-layout-of-go-project/
写的这么详细,诸位点个赞不过分吧!!!!
文章评论