Golang 之禪

在本月初的 GopherCon 上，知名 Go 語言貢獻者與佈道師 Dave Cheney 發表了名爲《The Zen of Go》的演講，以後他整理了演講內容在博客中分享，因爲內容過長，他又寫了一個簡潔版本：

• 完整版：dave.cheney.net/2020/02/23/…
• 簡潔版：the-zen-of-go.netlify.com

這裏簡單翻譯一下簡潔版本的內容：

編寫簡單、可讀、可維護的 Go 代碼的十個工程要點。

每一個包實現單一目標

設計良好的 Go 軟件包提供一個單一的思路，以及一系列相關的行爲。一個好的 Go 軟件包首先須要選擇一個好名字，使用電梯法則（30 秒內向客戶講清楚一個方案），僅用一個詞來思考你的軟件包要提供什麼功能。

明確處理錯誤

健壯的程序實際上是由處理故障案例的片斷組成的，而且須要在故障出現以前處理好。冗餘的if err != nil { return err }比出了故障再一個個去處理更有價值。panic 和 recover 也同樣。

儘早 return，不要深陷

每次縮進時都會在程序員的堆棧中添加另外一個先決條件，這會佔用他們短時間內存中的 7±2 個片斷。避免須要深層縮進的控制流。與其深刻嵌套，不如使用守衛子句將成功路徑保持在左側。

併發權留給調用者

讓調用者選擇是否要異步運行你的庫或函數，不要強制他們使用異步。

在啓動 goroutine 以前，要知道它何時會中止

goroutines 擁有資源、鎖、變量與內存等，釋放這些資源的可靠方法是中止 goroutine。

避免包級別的狀態

要完成明確和減小耦合的操做，須要經過提供類型須要的依賴項做爲該類型上的字段，而不是使用包變量。

簡單性很重要

簡單性不是老練的代名詞。簡單並不意味着粗糙，它意味着可讀性和可維護性。若是能夠選擇，請遵循較簡單的解決方案。

編寫測試以確認包 API 的行爲

軟件包的 API 是與使用者的一份合約，無論前後，無論多少，必定要進行測試。測試是肯定合約的保證。要確保測試使用者能夠觀察和依賴的行爲。

若是你認爲速度緩慢，先經過基準測試進行驗證

以性能之名會犯下許多危害可維護性的罪行。優化會破壞抽象、暴露內部和緊密耦合。若是要付出這樣的代價，請確保有充分理由這樣作。

節制是一種美德

適度使用 goroutine、通道、鎖、接口與嵌套。

文章轉載自 OSCHINA 社區 [http://www.oschina.net]

本文地址：www.oschina.net/news/113606…