本文转载自微信公众号《我的大脑是炸鱼》，作者陈建宇。转载本文请联系脑筋急转弯公众号。大家好，我是炸鱼。前段时间，Go语言社区里有一场热议，那就是golang-standards/project-layout项目的《Go项目的标准布局》之争。没想到五一假期，仔细一看，这个问题已经提了将近一个月了，还处于热议阶段。我认为我们需要好好谈谈这个话题。剑鱼带你了解前因后果，然后分享我的看法和真实的商业情况。背景问题是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：应用的依赖，可以通过执行gomodvendor获取。/configs：配置文件模板或默认配置。/init：系统初始化（systemd、upstart、sysv）和进程管理（runit、supervisord）配置。/scripts::用于执行各种构建、安装、分析等操作的脚本。更具体的layout介绍可以参考project-layout项目的README，基本上把目录的方方面面都考虑到了（很多人厉害）。由于内容太长，就不一一展示了。RussCox出现的原因只是一个巧合。该项目的作者是前谷歌员工，也是gopl.io项目（5.1kstars）的作者。仅仅过了23分钟，作为GoTeamLeader的RussCox(@rsc)就出现了，并提出了一个新的issue来表达他的反对意见：在golang-standards/project-layout项目的README中，明确表示这不是官方的标准有如下主张：它是一套Go生态系统中常见的历史和新兴项目布局模式。RussCox主要针对“这是Go生态系统中一套常见的历史和新兴项目布局模式”这一说法表达了一种“不准确”的观点。例如：Go生态系统中的绝大多数包不会将可导入的包放在pkg子目录中。更广泛地说，这里描述的只是非常复杂的工程项目，而Go的存储库往往要简单得多。另外，不幸的是，这套项目布局在组织名称中被称为“golang-standards”（Golang标准）。事实上，它并不是真正的官方标准，并且存在误导的情况。RussCox反对的原因是在了解了project-layout项目提供的“标准”项目布局和RussCox问题的背景之后。我们进一步了解RussCox认为这是不对的潜在考虑。project-layout项目有两个问题：它声称是Go标准的发起者，但其实不是，因为这些标准绝不是官方的Go标准。它提出的项目布局标准过于复杂，不是一个合理的标准。Go项目布局的标准是什么在提出这个问题后，很多人问RussCox，Go项目的布局标准是什么？RussCox给出了一个正式的回应，一个可导入的Go仓库的最低标准布局是：在你的根目录中放置一个LICENSE文件。将go.mod文件放在您的根目录中。将Go代码放在存储库中、根目录中，或者按照您认为合适的方式组织到目录树中。就是这样，它是“标准”，并没有那么复杂。不需要像project-layoutproject这样的布局。正如项目布局所说，Go的官方golang.org/x存储库之类的东西打破了这些“规则”中的每一个。Go提案经过长时间的口水战，有人在Go官方仓库提出了希望发布相关提案的提案：猜测可能有以下几种可能：GitHub项目golang-standards/project-layout是愿意改名，不再自称是“golang-standards”，但可能性比较小，因为很多人都提出了，但作者无话可说。Go官方提供了Go标准项目布局的描述。Go官方不强加约束，只发表意见，可能会输出文章。以后继续关注提案，就能知道进展。门户网站：问题#45861。按照惯例，我猜第三种可能性是最多的，因为任何人都很难提供一个所有开发者都认可的标准，每个业务部门和团队的喜好可能都不一样。总结其实，凡是标榜“XX标准”的东西，出名后都会带来一些问题。就像本文提到的golang-standards/project-layout项目。以另一种方式考虑它。如果你是某个项目的负责人，有一天你的同事被人建议修改“标准”，你会不会觉得这是这个项目的“标准”？巧合的是，我有一个朋友。他们公司早年只有一套DDD标准，想统一。于是，每一个参与DDD的商科学生都认为前辈们不标准，大家一起创造了一套DDD标准。总会有人想要定义绝对的“标准”或“最佳实践”。其实很难界定。最好的是能够在团队内部形成基本的共识，这不仅仅涉及技术……
