Go的标准项目布局(译)

Go的标准项目布局

这是Go应用程序项目的基本布局。它不是核心Go开发团队定义的官方标准;然而,它是Go生态系统 中一组常见的历史和新兴项目布局模式。其中一些模式比其他模式更受欢迎。它还有许多小的增强 功能,以及任何足够大的真实世界应用程序共有的几个支持目录。

如果您正在尝试学习Go或者您正在为自己构建PoC或不成熟的项目,那么这个项目布局是一种过度 杀伤力。从一些非常简单的东西开始(单个main.go文件绰绰有余)。随着项目的增长,请记住, 确保代码结构良好非常重要,否则终会出现带有大量隐藏依赖项和全局状态的混乱代码。当你有 更多的人参与这个项目时,你需要更多的结构。这就是介绍管理包/库的常用方法的重要性。当您有 一个开源项目或者您知道其他项目时,从您的项目存储库导入代码,这时私有(也就是内部)包和 代码很重要。克隆存储库,保留所需内容并删除其他所有内容!仅仅因为它在那里并不意味着你必 须全部使用它。在每个项目中都没有使用这些模式。甚至供应商模式也不普遍。

此项目布局是有意通用的,它不会尝试强加特定的Go包结构。

这篇文章这是社区的努力。如果您看到新模式或者您认为某个现有模式需要更新,请在git上提出问 题。

如果您需要有关命名,格式化和样式的帮助,请运行gofmt和golint。另外,请务必阅读这些Go代码 样式指南和建议:

https://talks.golang.org/2014/names.slide
https://golang.org/doc/effective_go.html#names
https://blog.golang.org/package­names
https://github.com/golang/go/wiki/CodeReviewComments

有关其他背景信息,请参阅Go Project Layout。

有关命名和组织包以及其他代码结构建议的更多信息:

GopherCon EU 2018: Peter Bourgon ­ Best Practices for Industrial Programming
GopherCon Russia 2018: Ashley McNamara + Brian Ketelsen ­ Go best practices.
GopherCon 2017: Edward Muller ­ Go Anti­Patterns
GopherCon 2018: Kat Zien ­ How Do You Structure Your Go Apps

Go的目录

 /cmd

该项目的主要应用。
每个应用程序的目录名称应与您要拥有的可执行文件的名称相匹配(例如,/ cmd / myapp)。
不要在应用程序目录中放入大量代码。如果您认为代码可以导入并在其他项目中使用,那么它应该 存在于/ pkg目录中。如果代码不可重用或者您不希望其他人重用它,请将该代码放在/ internal目录
中。你会惊讶于别人会做什么,所以要明确你的意图!
通常有一个小的main函数可以导入和调用/ internal和/ pkg目录中的代码而不是其他内容。 有关示例,请参阅/ cmd目录。

/internal

私有的应用程序和库的代码。这是您不希望其他人在其应用程序或库中导入的代码。
将您的实际应用程序代码放在/ internal / app目录(例如/ internal / app / myapp)和/ internal / pkg 目录中这些应用程序共享的代码(例如/ internal / pkg / myprivlib)。

/pkg

可以由外部应用程序使用的库代码(例如,/ pkg / mypubliclib)。其他项目将导入这些库,期望它 们可以工作,所以在你把东西放在这里之前要三思而后行:­)
当你的根目录包含许多非Go组件和目录时,它也可以在一个地方将Go代码分组,从而更容易运行 各种Go工具(如GopherCon EU 2018的工业编程佳实践中所述)。
如果要查看哪个流行的Go repos使用此项目布局模式,请参阅/ pkg目录。这是一种常见的布局模 式,但它并未被普遍接受,Go社区中的一些人不推荐它。

/vendor

应用程序依赖项(手动管理或由您喜欢的依赖管理工具(如dep)管理)。
如果要构建库,请不要提交应用程序依赖项。

服务应用程序目录

/api

OpenAPI / Swagger规范,JSON模式文件,协议定义文件。
有关示例,请参阅/ api目录。

Web应用程序目录

/web

特定于Web应用程序的组件:静态Web资产,服务器端模板和SPA。

常见应用程序目录

/configs

配置文件模板或默认配置。
将您的confd或consul­template模板文件放在这里。

/init

系统初始化(systemd,upstart,sysv)和进程管理器/主管(runit,supervisord)配置。

/scripts

脚本执行各种构建,安装,分析等操作。
这些脚本使根级Makefile保持简洁(例如, https://github.com/hashicorp/terraform/blob/master/Makefile)。
有关示例,请参阅/ scripts目录。

/build

打包和持续集成。
将您的云(AMI),容器(Docker),OS(deb,rpm,pkg)包配置和脚本放在/ build / package 目录中。
将CI(travis,circle,drone)配置和脚本放在/ build / ci目录中。请注意,某些CI工具(例如, Travis CI)对其配置文件的位置非常挑剔。尝试将配置文件放在/ build / ci目录中,将它们链接到CI 工具所期望的位置(如果可能)。

/deployments

IaaS,PaaS,系统和容器编排部署配置和模板(docker­compose,kubernetes / helm,mesos, terraform,bosh)。

/test

其他外部测试应用和测试数据。您可以随意构建/ test目录。对于更大的项目,有一个数据子目录是 有意义的。例如,如果需要Go忽略该目录中的内容,可以使用/ test / data或/ test / testdata。请注 意,Go也会忽略以“.”开头的目录或文件。或“_”,因此您在命名测试数据目录方面具有更大的灵活 性。
有关示例,请参阅/ test目录。

其他目录

/docs

设计和用户文档(除了你的godoc生成的文档)。
有关示例,请参阅/ docs目录。

/tools

该项目的支持工具。请注意,这些工具可以从/ pkg和/ internal目录导入代码。
有关示例,请参见/ tools目录。

/examples

应用程序和/或公共库的示例。
有关示例,请参阅/ examples目录。

/third_party

外部帮助工具,分叉代码和其他第三方实用程序(例如,Swagger UI)。

/githooks

Git hooks.

/assets

与您的存储库一起使用的其他资产(images, logos, etc)。

/website

如果您不使用Github页面,这是放置项目的网站数据的地方。
有关示例,请参阅/ website目录。

你不应该有的目录

/src

一些Go项目确实有一个src文件夹,但它通常发生在开发人员来自Java世界时,它是一种常见的模 式。如果您可以帮助自己尝试不采用此Java模式。你真的不希望你的Go代码或Go项目看起来像 Java :­)
不要将项目级别/ src目录与Go用于其工作空间的/ src目录混淆,如如何编写Go代码中所述。 环境变量指向您的(当前)工作空间(默认情况下,它指向非 系统上的 HOME / go)。此工作空间包括顶级/ pkg,/ bin和/ src目录。您的实际项目终成为/ src下的子目录,因此 如果项目中有/ src目录,项目路径将如下所示:/ some / path / to / workspace / src / your_project / src / your_code。请注意,使用Go 1.11可以将项目置于GOPATH之外,但这并不意味着使用此布 局模式是个好主意。

Badges

Go Report Card­它将使用gofmt,go vet,gocyclo,golint,ineffassign,license和misspell扫描你 的代码。将github.com/golang­standards/project­layout替换为您的项目参考。
GoDoc ­ 它将提供GoDoc生成文档的在线版本。更改链接以指向您的项目。
Release­它将显示项目的新版本号。更改github链接以指向您的项目。

脚注

具有可复用的配置,脚本和代码的更具见解性的项目模板是WIP。

你可能感兴趣的:(每日学习)