[[397785]]

本文轉載自微信公眾號「腦子進煎魚了」，作者陳煎魚。轉載本文請聯系腦子進煎魚了公眾號。

大家好，我是煎魚。

前段時間 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 標準。

總是會有小伙伴想讓定義絕對的 “標準”，又或是 “最佳實踐”。其實是難以定義的，最好的就是能夠一個團隊內形成基本共識，這里面牽扯到的不單單只有技術...