無需花時間試圖弄清楚如何將代碼分解為軟件包，而是采用扁平結構的應用程序會將所有.go文件放置在一個軟件包中。

myapp/   main.go   server.go   user.go   lesson.go   course.go

進入Go時，幾乎每個人都從一個平面應用程序結構開始。 Go tour中的每個程序，Gophercises中的大多數練習以及許多其他早期的Go程序都沒有被分解成任何包裝。取而代之的是，我們只創(chuàng)建幾個.go文件，然后將所有代碼放入相同的(通常是main)包中。

起初，這聽起來很糟糕。代碼會很快變得笨拙嗎？如何將業(yè)務邏輯與UI渲染代碼分開？我如何找到正確的源文件？畢竟，我們使用軟件包的很大一部分原因是要分離關注點，同時使更容易快速地導航到正確的源文件。

相關學習推薦：Go語言教程

有效使用平面結構

使用平面結構時，您仍應嘗試遵守編碼最佳實踐。您將需要使用不同的.go文件分隔應用程序的不同部分：

myapp /   main.go#閱讀配置并在此處啟動您的應用   server.go#總體HTTP處理邏輯在這里   user_handler.go#用戶http處理程序邏輯在這里   user_store.go#用戶數據庫邏輯在這里   # 等等...

全局變量仍然可能成為問題，因此您應考慮將類型與方法配合使用，以使它們脫離代碼：

type Server struct {   apiClient *someapi.Client   router *some.Router }  func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {   s.router.ServeHTTP(w, r) }

而且您的main()函數可能仍應在設置應用程序之外刪除大多數邏輯：

//警告：此示例非常人為設計，甚至可能無法編譯。  type Config struct {   SomeAPIKey     string   Port           string   EnableTheThing bool }  func main() {   var config Config   config.SomeAPIKey = os.Getenv("SOMEAPI_KEY")   config.Port = os.Getenv("MYAPP_PORT")   if config.Port == "" {     config.Port = "3000"   }   config.EnableTheThing = true    if err := run(config); err != nil {     log.Fatal(err)   } }  func run(config Config) error {   server := myapp.Server{     APIClient: someapi.NewClient(config.SomeAPIKey),   }   return http.ListenAndServe(":" + config.Port, server) }

實際上，您實際上可以將基本上是平面結構的代碼全部使用在一個軟件包中，并在單獨的main軟件包中定義命令。這將允許您使用常見的cmd子目錄模式：

myapp/   cmd/     web/       # package main       main.go     cli/       # package main       main.go   # package myapp   server.go   user_handler.go   user_store.go   ...

在此示例中，您的應用程序基本上仍然是平坦的，但是您拔出了main軟件包是因為您有需要-例如可能需要使用同一核心應用程序來支持兩個命令。

為什么要使用扁平結構？

扁平結構的主要好處不是將所有代碼都保存在一個目錄中，也不是那樣愚蠢的東西。這種結構的核心好處是您可以不必擔心如何組織事物，而可以繼續(xù)解決您打算通過應用程序解決的問題。

我絕對喜歡這個應用程序結構讓我回想起PHP的日子。當我第一次學習編碼時，我開始使用隨機PHP文件，其邏輯與各種HTML混合在一起，這真是一團糟。我并不是在建議我們以大型應用程序的方式構建-那樣會很糟糕-但是我并不擔心一切都應該放在哪里，而是更加關注學習如何編寫代碼和解決我的特定問題。無論您是要了解應用程序的需求，您的域還是一般的編碼方式，使用扁平結構都可以使您更輕松地專注于學習和構建。

這是正確的，因為我們可以不再擔心諸如“這種邏輯應該去哪里？”之類的問題。因為如果我們犯了一個錯誤，很容易解決。如果它是一個函數，我們可以將其移動到包中的任何新源文件中。如果它是錯誤類型的方法，我們可以創(chuàng)建兩個新類型并將邏輯與原始類型分開。有了這些，我們就不必擔心會遇到奇怪的周期性依賴問題，因為我們只有一個軟件包。

考慮平面結構的另一個重要原因是，隨著應用程序復雜性的提高，結構的發(fā)展變得容易得多。當您明顯可以從將代碼拆分到一個單獨的程序包中受益時，您通常需要做的就是將一些源文件移到一個子目錄中，更改其程序包，并更新任何引用以使用新的程序包前綴。例如，如果我們有SqlUser并決定從一個單獨的sql包中處理所有與數據庫相關的邏輯中受益，我們將更新所有引用以現在使用sql.User將類型移動到新軟件包后。我發(fā)現，像MVC這樣的結構在重構方面更具挑戰(zhàn)性，盡管并非沒有其他編程語言那樣困難或困難。

扁平結構對于通常太快無法創(chuàng)建包的初學者特別有用。我真的不能說為什么會發(fā)生這種現象，但是Go的新手喜歡創(chuàng)建大量的軟件包，這幾乎總是導致口吃(user.User)，周期性依賴關系或其他一些問題。

在下一篇有關MVC的文章中，我們將探討這種創(chuàng)建過多包的現象如何使MVC在Go中顯得不可能的方法，盡管事實并非如此。

通過推遲創(chuàng)建新程序包的決定，直到我們的應用程序增長一點并更好地了解它，發(fā)芽的Gophers犯此錯誤的可能性就大大降低了。

這也是為什么很多人會鼓勵開發(fā)人員避免過早將其代碼分解到微服務中的原因-您通常沒有足夠的知識來真正知道應該和不應該將哪些內容分解為微服務以及搶先式微服務( I kinda希望能成為一句俗語)只會在將來帶來