God's perspective on the "Go project standard layout" controversy

Hello everyone, I am fried fish.

Some time ago, there was a hot discussion in the Go language community, and that was the golang-standards/project-layout over the “standard layout of the Go project” of the 061471132e008e project.

Unexpectedly, during the May 1st holiday, take a closer look, this issue has been raised for nearly a month, and it is still in the hot discussion stage. I think we need to talk about this topic.

Fried fish will take you to understand the causes and consequences, and then share my views and the real situation of the business.

background

Where the problem occurred

There is a project Spaghetti (github.com/adonovan/spaghetti) on GitHub, which is a dependency analysis tool for Go packages.

The directory structure of the project is as follows:

It doesn't look complicated, the amount of code is small, and the files are not tiled more than one screen. It is a project with a relatively simple layout.

An old man put forward a PR, clearly expecting the project to be adjusted in accordance with the "standard" layout given by the golang-standards/project-layout :

I guess that the project may be due to the combination of Go, HTML, JS, PNG, and go.mod files, which caused a bit of entanglement for the student. I feel that it is messy?

What does the "standard layout" look like

In the golang-standards/project-layout project, it claimed:

The organization name of the project is also "golang-standards", which provides a basic Go project layout, simplified and shown as follows:

project-layout
├── api
├── cmd
├── configs
├── docs
├── go.mod
├── init
├── internal
├── pkg
├── scripts
├── vendor
├── ...

• /cmd: The main application of the project.
• /internal: Private application code library. These are codes that you don't want to be imported by others.
• The actual code of the application can be placed in the /internal/app directory (for example: internal/app/myapp).
• The shared code of the application is placed in the /internal/pkg directory (for example: internal/pkg/myprivlib).
• /pkg: Library code that can be used by external applications (for example: /pkg/mypubliclib). Other projects will import these libraries to ensure that the project can run normally.
• /vendor: Application dependencies, which can be obtained by executing go mod vendor .
• /configs: Configuration file template or default configuration.
• /init: System initialization (systemd, upstart, sysv) and process management (runit, supervisord) configuration.
• /scripts:: Scripts used to perform various construction, installation, analysis and other operations.

For a more detailed introduction to the layout, you can refer to the README of the project-layout project, which basically takes into account all aspects of the catalog (there is a lot of people and power).

Since the content is too long, it will not be shown one by one.

Russ Cox's appearance

Coincidentally, the author of the project is a former Google employee and the author of the gopl.io project (5.1k stars).

After only 23 minutes passed, Russ Cox (@rsc) as the GoTeam Leader appeared and raised a new issue to express his opposition:

In golang-standards/project-layout project, it is clearly stated that this is not an official standard, with the following claims:

it is a set of common historical and emerging project layout patterns in the Go ecosystem.

Russ Cox mainly expressed an "inaccurate" opinion on the claim that "this is a common historical and emerging project layout pattern in the Go ecosystem".

For example, most packages in the Go ecosystem will not place importable packages in the pkg subdirectory. More broadly, what is described here is only a very complex engineering project, and Go's warehouse is often much simpler.

In addition, unfortunately, this set of project layouts is called "golang-standards" (Golang standard) in the name of the organization. In fact, it is not really an official standard, and it is misleading.

Reasons for Russ Cox's Objection

After understanding the "standard" project layout provided by the project-layout project and the background of Russ Cox's issues.

We further understand that Russ Cox believes that is not a fundamental consideration The project-layout project has two problems:

• It claims to be the sponsor of Go standards, but it is not the case because these standards are by no means official Go standards.
• The project layout standard it proposed is too complicated and not a reasonable standard.

What are the standards for Go project layout

After raising this issue, a lot of people appeared to ask Russ Cox, what is the layout standard of the Go project?

Russ Cox gave a formal response. The minimum standard layout of an importable Go repo is:

• Put a LICENSE file in your root directory.
• Put a go.mod file in your root directory.
• Put the Go code in the repo, in the root directory, or organize it into a directory tree as you see fit.

That's it, this is the "standard", not that complicated. No need for the same layout as the project-layout project. For example, the official Go golang.org/x breaks every one of these "rules" mentioned by project-layout.

Go proposal

After a long war of words, someone has already put forward a proposal in the Go official warehouse hoping to release the relevant proposal (proposal):

There may be several possibilities for guessing:

• The GitHub project golang-standards/project-layout is willing to change its name and no longer call itself "golang-standards", but the possibility is relatively low because many people have already proposed it, but the author has nothing to say.
• Go officially provides instructions on the layout of the Go standard project.
• Go official does not make constraints, only expresses opinions, and may output articles.

Follow-up everyone continues to pay attention to the proposal, you can know the development, portal: issues #45861.

By convention, I guess the third possibility is the greatest, because it is difficult for someone to provide all the standards recognized by developers, and the preferences of each division and team may be different.

Summarize

In fact, anything that claims to be "XX Standard" will cause some problems when it becomes famous. Just like the golang-standards/project-layout project mentioned in this article.

Think about it in another way. If you are the leader of a certain project, and one day your colleague is suggested to modify with the "standard", would it be wonderful to say that this is the "standard" of this project?

Coincidentally, I have a friend. Their company only had a set of DDD standards in the early years and wanted to unify it. As a result, every business classmate involved in DDD later believed that the predecessors were not standard, and everyone created a set of DDD standards.

There will always be small partners want to define absolute "standards" or "best practices" . In fact, it is difficult to define. The best thing is to be able to form a basic consensus within a team. It involves not only technology...

What is your opinion on this, welcome to leave a message in the comment area to communicate with you !

If you have any questions, welcome feedback and exchanges in the comment area. The best relationship between . Your likes is the greatest motivation for the creation of fried fish

The article is continuously updated, and you can read it on WeChat search [ 000 ] There are the first-line interview algorithm questions and information prepared by me.

This article GitHub github.com/eddycjy/blog has been included, welcome Star to remind you.