大家好，我是煎鱼。
前段时间 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 催更。