共计 2825 个字符,预计需要花费 8 分钟才能阅读完成。
大家好,我是煎鱼。
前段时间 Go 语言社区有一件事件引爆了热议,那就是 golang-standards/project-layout
我的项目的“Go 我的项目的规范布局”之争。
没想到,五一假期,认真一看,这个 issues 曾经提出将近一个月了,依然在热议阶段,我想,咱们须要好好的聊聊这个话题。
煎鱼带你理解下的前因后果,再分享我的认识和业务真实情况。
背景
问题发生地
在 GitHub 上有一个我的项目 Spaghetti(github.com/adonovan/spaghetti),是 Go 软件包的一个依赖性剖析工具。
该项目标目录构造如下:
看上去并不简单,代码量不多,文件平铺也不超过一屏,就是一个布局比较简单的我的项目。
有一位老哥提出了一个 PR,明确的冀望该我的项目依照 golang-standards/project-layout
我的项目给出的“规范”布局来调整。:
我猜想该我的项目可能是因为把 Go、HTML、JS、PNG 和 go.mod 文件等摆在了一起,引起了该同学的一丝丝纠结,感觉比拟乱?
“规范布局“长什么样子
在 golang-standards/project-layout
我的项目中,其自称:
我的项目的组织名也是 “golang-standards”,其提供了一个根本的 Go 我的项目布局,精简展现如下:
project-layout
├── api
├── cmd
├── configs
├── docs
├── go.mod
├── init
├── internal
├── pkg
├── scripts
├── vendor
├── ...
- /cmd:我的项目次要的应用程序。
- /internal:公有的利用程序代码库,这些是不心愿被其他人导入的代码。
- 应用程序理论的代码能够放在 /internal/app 目录(如:internal/app/myapp)。
- 应用程序的共享代码放在 /internal/pkg 目录(如:internal/pkg/myprivlib)中。
- /pkg:内部应用程序能够应用的库代码(如:/pkg/mypubliclib)。其余我的项目将会导入这些库来保障我的项目能够失常运行。
- /vendor:应用程序的依赖关系,可通过执行
go mod vendor
执行失去。 - /configs:配置文件模板或默认配置。
- /init:零碎初始化(systemd、upstart、sysv)和过程治理(runit、supervisord)配置。
- /scripts::用于执行各种构建,装置,剖析等操作的脚本。
更具体的布局介绍,大家能够参见 project-layout 我的项目的 README,其根本把方方面面的目录都思考到了(人多力量大)。
因为内容过于长,因而就不一一展现了。
Russ Cox 现身起因
不过很巧,该项目标作者是前 Google 员工,是 gopl.io
我的项目(5.1k stars)的作者。
在仅仅过来 23 分钟后,作为 GoTeam Leader 的 Russ Cox(@rsc)就现身,并提出新的 issue 表白出了拥护意见:
在 golang-standards/project-layout
我的项目的 README 中有明确指出这不是官网的规范,有如下宣称:
it is a set of common historical and emerging project layout patterns in the Go ecosystem.
Russ Cox 次要是对宣称 “ 这是一套 Go 生态系统中常见的历史和新兴的我的项目布局模式 ” 这一说法示意了“不精确”的意见。
例如:Go 生态系统中的绝大多数包都不会将可导入的包放在 pkg 子目录中。更宽泛地说,这里形容的只是非常复杂的工程项目,而 Go 的仓库往往要简略得多。
另外,可怜的是,这套我的项目布局在组织名字上被称作 “golang-standards”(Golang 规范)提出来,实际上并非真的是官网规范,有误导的状况存在。
Russ Cox 拥护起因
在理解 project-layout 我的项目所提供的“规范“我的项目布局和 Russ Cox 提出 issues 的背景后。
咱们进一步理解 Russ Cox 认为 这不对 的基本思考。project-layout 这个我的项目有两个问题:
- 它宣称是 Go 规范(Go standards)的主办方,但实际上并非如此,因为这些规范绝非 Go 官网规范。
- 它提出的我的项目布局规范过于简单,不是一个正当的规范。
Go 我的项目布局的规范是什么
提出这个 issues 后,呈现了一大堆人诘问 Russ Cox,到底何为 Go 我的项目的布局规范?
Russ Cox 给出了正式回应,一个可导入的 Go repo 的最小规范布局是:
- 在你的根目录下放一个 LICENSE 文件。
- 在你的根目录下放一个 go.mod 文件。
- 将 Go 代码放在 repo 中,放在根目录中,或者依照你认为适合的形式组织成一个目录树。
就这样了,这就是 “ 规范 ”,没有那么简单。不须要像 project-layout 我的项目一样的布局。像是 Go 官网的 golang.org/x
仓库突破了 project-layout 所说的这些 “ 规定 “ 中的每一条。
Go 提案
在经验了长时间的口水战后,曾经有人在 Go 官网仓库提出心愿释出相干的提案(proposal):
猜想可能会有如下几种可能:
- GitHub 我的项目 golang-standards/project-layout 违心更名,不再自称”golang-standards“,不过可能性比拟低,因为曾经已多人提出,但作者没什么示意。
- Go 官网正式提供 Go 规范我的项目布局的阐明。
- Go 官网不做束缚,仅做表态,可能输入文章。
后续大家持续关注该提案,就能够晓得倒退了,传送门:issues #45861。
依照常规,我猜想第三种可能性最大,因为很难有人能够提供所有开发者认可的规范,每个事业部、团队的爱好都可能有所不同。
总结
实际上,任何货色自称“XX 规范”,在名气大后,都会带来一些问题。就像本文提到的 golang-standards/project-layout 我的项目一样。
换位思考一下,若你是某个我的项目的 Leader,某一天你的共事,被人拿着“规范”来倡议批改时,说这是这个我的项目的“规范”,会不会很微妙?
独一无二,我有一个敌人,他们公司早年只有一套 DDD 规范,本想对立。后果前面每一个染指 DDD 的业务同学,都认为前人不规范,每个人都借鉴了一套 DDD 规范。
总是会有小伙伴 想让定义相对的“规范”,又或是“最佳实际”。其实是难以定义的,最好的就是可能一个团队内造成根本共识,这外面牵扯到的不单单只有技术 …
你对此有什么认识呢,欢送在评论区留言和大家一起交换!
若有任何疑难欢送评论区反馈和交换,最好的关系是相互成就 ,各位的 点赞 就是煎鱼创作的最大能源,感激反对。
文章继续更新,能够微信搜【脑子进煎鱼了】浏览,回复【000】有我筹备的一线大厂面试算法题解和材料。
本文 GitHub github.com/eddycjy/blog 已收录,欢送 Star 催更。