Go Module 時代項目結構最佳實踐

Go 應用的標準項目結構是一個有點爭議的話題。一些人堅持認爲，每個人的每個項目都應該遵循大家都推薦的 golang-standards/project-layout（https://github.com/golang-standards/project-layout）佈局結構。

然而隨着 Go Modules 作爲處理依賴關係的標準被引入，這種結構開始面臨挑戰。如果採用傳統的結構，你會發現你的結構中的一些文件夾將無法訪問諸如internal或pkg之類的文件夾，你將不得不用比較繞的方案才能在這種項目結構下編程。

在這篇文章中，我將介紹在新的 go modules 體系下項目結構的較好實踐。

注意，在組織應用項目結構時，沒有 "一勞永逸" 的方法。隨着應用程序的發展，項目結構化方法也必須隨之改變。

小型應用程序 - 扁平結構

每個項目都是從小開始長大。能長到多大，取決於項目的成功程度或開發者願意爲它貢獻多少時間。

application/
 - main.go
 - main_test.go
 - utils.go
 - utils_test.go
 - ...

強烈建議從扁平化的文件夾結構開始。作爲開發者，通過保持項目結構的簡單性可以專注於盡快將最高價值的功能交付給你的目標受衆，而不需要複雜結構的認知開銷。

我經常看到開發人員在項目的早期階段、在任何真正有價值的東西被交付之前，就花費很多的時間來安排和重新整理他們的代碼結構，這會讓開發者和目標受衆之間的反饋時間變長。

收益

這種扁平化的文件夾結構在開發的時候是非常理想的。

這種結構的例子

這個項目幾乎完美地詮釋了一個項目如何在極簡的結構下獲得成功。他們從一開始就把所有的東西都保持得非常扁平化，沒有把事情搞得太複雜，同時專注於爲使用項目的人提供真正的價值。

另一個非常酷的項目，其特點是完全扁平的項目結構。

中 / 大型應用 -- 模塊化

隨着項目規模和複雜度的增長，你會很快發現扁平結構不能滿足編程需求了，這時應該開始考慮將代碼庫模塊化。

以一個網站的 Rest API 接口項目爲例，這些接口裏有登陸註冊的接口、還有 CURUD 處理用戶內容的接口。

這時應該開始考慮將我們的應用程序按照語義拆分成各功能組，將這些組件之間共享的任何核心邏輯集中到項目中的共享包中。

rest-api/
- main.go
- user/
- - user.go
- - login.go
- - registration.go
- articles/
- - articles.go
- utils/
- - common_utils.go

這種結構的例子

是一個採用這種結構的項目的優秀例子。他們將項目分解成 IAAS 雲提供商的每個包，每個包都包含了與該特定雲提供商相關的所有代碼。

這是另一個選擇採用模塊化方法的大型項目的好例子。

IPFS 是一個非常酷的點對點文件系統，用 Go 編寫，基於 Git 和 BitTorrent 等系統。他們在開發系統時也選擇了模塊化的方法。

這個框架很贊，是我博客的網站後臺框架！

成熟項目

當然我們還是能看到堅持之前說的 “最佳” 項目結構的項目，但這在很大程度上是這些應用程序開發時的副產品。

像 Hashicorp 的 Terraform 或 Google 的 Kubernetes 這樣的大型應用，往往會保留舊式結構，在 $GOPATH 至上的時候，這種結構非常好用。你會看到，它們仍然具有internal和pkg文件夾的特點。這些文件夾封裝了項目的一些內部工作。

這種結構運作得非常好，幫助開發者爲社區貢獻了極高的價值。然而我認爲，隨着 Go modules 開始用得越來越普遍，我們將看到這些應用程序從更傳統的結構遷移到一個更新的結構。

項目拆分

到了一定程度後，將項目中某些有意義的部分完全剝離出來，變成有自己生命週期的獨立倉庫也是有意義的。

搞獨立項目有一系列缺點，比如在管理整個項目的更新時會增加開銷。但這也意味着你的項目將更容易吸引那些想要貢獻的項目新人。

總結

希望這篇文章能對你的開發工作有所幫助，給你啓動新項目帶來一些思路!

這些都是我自己基於在日常工作中開發服務的經驗。在使用這些結構時，你自己的開發過程可能會有所不同。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Yim7rY5KWeQsgqOvDV1muw

猜你喜歡