注意:这个问题和这个问题相关,但是两年在围棋历史上是很长的时间。
在开发过程中组织Go项目的标准方法是什么?
我的项目是一个单独的包mypack,所以我想我把所有的.go文件放在一个mypack目录中。
然后,我想在开发过程中测试它,所以我至少需要一个声明主包的文件,这样我就可以运行trypack。go
我该怎么组织呢?每次我都需要安装mypack吗?
注意:这个问题和这个问题相关,但是两年在围棋历史上是很长的时间。
在开发过程中组织Go项目的标准方法是什么?
我的项目是一个单独的包mypack,所以我想我把所有的.go文件放在一个mypack目录中。
然后,我想在开发过程中测试它,所以我至少需要一个声明主包的文件,这样我就可以运行trypack。go
我该怎么组织呢?每次我都需要安装mypack吗?
当前回答
我研究过许多围棋项目,其中有相当多的变化。你可以看出谁来自C,谁来自Java,因为前者将项目根目录中的所有内容转储到主包中,而后者倾向于将所有内容放在src目录中。然而,这两种方法都不是最佳的。每种方法都会产生后果,因为它们会影响导入路径以及其他人如何重用它们。
为了得到最好的结果,我想出了以下方法。
myproj/
main/
mypack.go
mypack.go
mypack的地方。Go是package mypack和main/mypack。Go显然是包的主体。
如果你需要额外的支持文件,你有两个选择。要么将它们全部保存在根目录中,要么将私有支持文件放在lib子目录中。如。
myproj/
main/
mypack.go
myextras/
someextra.go
mypack.go
mysupport.go
Or
myproj.org/
lib/
mysupport.go
myextras/
someextra.go
main/
mypack.go
mypage.go
只有当文件不打算被另一个项目导入时,才将它们放在lib目录中。换句话说,如果它们是私有支持文件。这就是lib背后的思想——将公共接口与私有接口分开。
这样做将为您提供一个良好的导入路径myproj.org/mypack,以便在其他项目中重用代码。如果使用lib,则内部支持文件将有一个指示性的导入路径myproj.org/lib/mysupport。
在构建项目时,使用main/mypack,例如去构建main/mypack。如果你有多个可执行文件,你也可以在main下分离它们,而不必创建单独的项目。如主要/ myfoo / myfoo。去main/mybar/mybar。去。
其他回答
我建议你看看这篇关于如何编写Go代码的文章
它记录了如何以一种友好的方式构建你的项目,以及如何编写测试。测试不需要是一个使用主包的cmd。它们可以简单地是TestX命名的函数,作为每个包的一部分,然后go test将发现它们。
你问题中那个链接中建议的结构有点过时了,现在随着Go 1的发布。您不再需要在src下放置pkg目录。只有3个与规范相关的目录是GOPATH根目录中的3:bin、pkg、src。在src下面,你可以简单地放置你的项目mypack,下面是你所有的。go文件,包括mypack_test.go
去构建,然后构建到根级PKG和bin。
所以你的GOPATH可能是这样的:
~/projects/
bin/
pkg/
src/
mypack/
foo.go
bar.go
mypack_test.go
出口GOPATH = $ HOME /项目
$ go build mypack
$ go test mypack
更新:从>= Go 1.11开始,模块系统现在是工具的标准组成部分,GOPATH概念接近过时。
我研究过许多围棋项目,其中有相当多的变化。你可以看出谁来自C,谁来自Java,因为前者将项目根目录中的所有内容转储到主包中,而后者倾向于将所有内容放在src目录中。然而,这两种方法都不是最佳的。每种方法都会产生后果,因为它们会影响导入路径以及其他人如何重用它们。
为了得到最好的结果,我想出了以下方法。
myproj/
main/
mypack.go
mypack.go
mypack的地方。Go是package mypack和main/mypack。Go显然是包的主体。
如果你需要额外的支持文件,你有两个选择。要么将它们全部保存在根目录中,要么将私有支持文件放在lib子目录中。如。
myproj/
main/
mypack.go
myextras/
someextra.go
mypack.go
mysupport.go
Or
myproj.org/
lib/
mysupport.go
myextras/
someextra.go
main/
mypack.go
mypage.go
只有当文件不打算被另一个项目导入时,才将它们放在lib目录中。换句话说,如果它们是私有支持文件。这就是lib背后的思想——将公共接口与私有接口分开。
这样做将为您提供一个良好的导入路径myproj.org/mypack,以便在其他项目中重用代码。如果使用lib,则内部支持文件将有一个指示性的导入路径myproj.org/lib/mysupport。
在构建项目时,使用main/mypack,例如去构建main/mypack。如果你有多个可执行文件,你也可以在main下分离它们,而不必创建单独的项目。如主要/ myfoo / myfoo。去main/mybar/mybar。去。
保持文件在同一目录下,并在所有文件中使用package main。
myproj/
your-program/
main.go
lib.go
然后运行:
~/myproj/your-program$ go build && ./your-program
让我们看看go get repository_remote_url命令如何管理$GOPATH下的项目结构。如果我们去获取github.com/gohugoio/hugo,它将克隆存储库
美元GOPATH / src / repository_remote / user_name / project_name
美元GOPATH / src / github.com/gohugoio/hugo
这是创建初始项目路径的好方法。现在,让我们探索一下有哪些项目类型,以及它们的内部结构是如何组织的。社区中所有的golang项目都可以分为
库(没有可执行二进制文件) 单个项目(只包含1个可执行二进制文件) 工具项目(包含多个可执行二进制文件)
一般来说,golang项目文件可以按照DDD、POD等任何设计原则进行打包
大多数可用的go项目都遵循这种面向包的设计
面向包设计鼓励开发人员只在自己的包中实现,而不是那些包之间不能通信的/内部包
库
诸如数据库驱动程序、qt等项目可以归入这一类。 一些库,如color,现在遵循扁平结构,没有任何其他包。 这些库项目大多管理一个名为internal的包。 /内部包主要用于对其他项目隐藏实现。 没有任何可执行二进制文件,因此没有包含main func的文件。
~/$GOPATH/
bin/
pkg/
src/
repository_remote/
user_name/
project_name/
internal/
other_pkg/
单项目
像hugo, etcd这样的项目在根级和中有一个单一的主函数。 目标是生成一个二进制文件
工具项目
kubernetes、go-ethereum等项目在一个名为cmd的包下组织了多个main func Cmd / package管理我们想要构建的二进制文件(工具)的数量
~/$GOPATH/
bin/
pkg/
src/
repository_remote/
user_name/
project_name/
cmd/
binary_one/
main.go
binary_two/
main.go
binary_three/
main.go
other_pkg/
似乎没有组织Go项目的标准方法,但https://golang.org/doc/code.html为大多数项目指定了最佳实践。Jdi的答案很好,但如果你使用github或bitbucket,你也有额外的库,你应该创建以下结构:
~/projects/
bin/
pkg/
src/
github.com/
username/
mypack/
foo.go
bar.go
mypack_test.go
mylib/
utillib.go
utillib_test.go
通过这样做,您可以为mylib拥有一个单独的存储库,可以用于其他项目,并且可以通过“go get”进行检索。你的mypack项目可以使用“github.com/username/mylib”导入你的库。欲了解更多信息:
http://www.alexvictorchan.com/2014/11/06/go-project-structure/