学习Golang时遇到的似懂非懂的概念

背景🐋

这是我学习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 目录或 pipvirtualenv 机制。
  • Makefile 包含了项目的构建与管理规则,如编译、测试、部署等。
  • README.md 文件包含了项目的说明文档和使用说明。

这种目录布局其实还挺清晰的,但是自从go引入go modules做依赖管理,项目布局结构会变得更精简,更灵活。具体目录布局如下所示:

.
├── cmd
│   └── main.go
├── internal
├── pkg
├── vendor
├── go.mod
└── README.md
  • cmd 目录是程序的入口代码,即 main 函数的实现。
  • internal 目录用于存放应用程序的私有代码,不能被其他项目引用。
  • pkg 目录用于存放应用程序的公共库代码,可以被其他项目引用。
  • vendor 目录用于存放依赖库的代码,类似于其他语言中的 node_modules 目录或 pipvirtualenv 机制。
  • 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.goadmin.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.TErrorFailFatal 函数,以及 testing.BReportAllocsResetTimerStopTimer 等函数。

下面是一个简单的测试示例,测试 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/

写的这么详细,诸位点个赞不过分吧!!!!

posted @ 2023-05-08 11:39  嘉沐  阅读(547)  评论(2编辑  收藏  举报