使用Go和使用其他編程語言中一樣，需要了解常見錯(cuò)誤和不良實(shí)踐，才能編寫既干凈又高效的代碼。

本文討論的一些實(shí)踐并不一定都是不好的，在特定情況下很有用。 然而，我們需要知道可能會(huì)有什么問題，為什么應(yīng)該回避某些習(xí)慣，以及如何避開常見的陷阱。

1. 使用init()

Go中的init()函數(shù)是一個(gè)特殊函數(shù)，在main函數(shù)之前執(zhí)行。

"如果初始化對(duì)于任何包都很重要，為什么init()在Go中被認(rèn)為是一個(gè)不好的做法?"

是的，雖然init()函數(shù)確實(shí)有助于在運(yùn)行核心邏輯之前進(jìn)行初始化，但其執(zhí)行順序可能很難理解，可能導(dǎo)致對(duì)初始化順序的混淆。

// package A
func init() {}

// package B 
func init() {}

// which run first?

想象一下，有兩個(gè)模塊在安裝時(shí)相互依賴，但位于不同的包中。結(jié)果我們最終需要編寫更復(fù)雜的代碼來管理時(shí)序，更糟的是，甚至可能陷入死鎖情況。

使用init()的另一個(gè)缺點(diǎn)是測(cè)試會(huì)變得復(fù)雜。因?yàn)檫@些函數(shù)是自動(dòng)運(yùn)行的，無法選擇何時(shí)執(zhí)行。

缺乏控制使得設(shè)置測(cè)試用例成為一項(xiàng)挑戰(zhàn)。

我曾經(jīng)遇到過一個(gè)問題，我的服務(wù)在部署后花了很長(zhǎng)時(shí)間才準(zhǔn)備好。我在main()函數(shù)的開始處設(shè)置了一個(gè)斷點(diǎn)，但從未觸發(fā)。

經(jīng)過冗長(zhǎng)的調(diào)試后，我們發(fā)現(xiàn)一個(gè)成員使用了某個(gè)包中的init()函數(shù)從一個(gè)大文件加載一個(gè)大數(shù)據(jù)集，這讓我們花費(fèi)大量時(shí)間去解決這么一個(gè)小問題。

2. 使用全局變量

Go中的全局變量可能會(huì)帶來類似單例的問題，特別是當(dāng)這些全局變量很復(fù)雜時(shí)(比如映射、切片或指針)。

"那么，全局變量有什么大不了的?"

• 競(jìng)爭(zhēng)條件: 當(dāng)有多個(gè)程序試圖同時(shí)訪問同一個(gè)全局變量時(shí)，事情可能會(huì)變得混亂。
• 更少的可測(cè)試性: 應(yīng)用程序依賴于全局變量，意味著有狀態(tài)，從而在單元或集成測(cè)試期間，這些全局變量需要與main()函數(shù)中的內(nèi)容或在生產(chǎn)環(huán)境中部署的內(nèi)容保持一致。
• 模塊化程度較低，可重用性較差: 可以從任何地方訪問全局變量，很難跟蹤其使用方式和位置。

因此，這里的建議是保持對(duì)包的封裝。

從而使得代碼更容易移動(dòng)，并且不太可能破壞其他東西。通過避免使用全局變量，可以使代碼不那么受約束，并且更容易更新或復(fù)用。

3. 忽略錯(cuò)誤信息

用Go編程時(shí)，錯(cuò)誤是不可避免的，知道如何處理錯(cuò)誤可以讓我們避免各種各樣的問題。

"忽略錯(cuò)誤真的那么糟糕嗎?"

是的，完全正確。

一些Go新手可能會(huì)用"_"符號(hào)將錯(cuò)誤撇在一邊，但忽略函數(shù)返回的錯(cuò)誤值，可能會(huì)帶來麻煩。

如果不對(duì)錯(cuò)誤進(jìn)行管理，也許程序會(huì)出現(xiàn)panic和crash。

// sample 1
func main() {
  var x interface{} = "hello"
  s := x.(int) // panic: interface conversion: interface {} is string, not int
  fmt.Println(s)
}

// sample 2
func main() {
  var x interface{} = "hello"
  s, _ := x.(int) // safe but DON'T
  fmt.Println(s)
}

跳過錯(cuò)誤可能會(huì)適得其反，尤其是對(duì)于線上生產(chǎn)環(huán)境，調(diào)試會(huì)成為一場(chǎng)噩夢(mèng)。總是--我的意思是總是--檢查錯(cuò)誤并采取正確的措施以保持代碼順利運(yùn)行。

4. 避免GOTO

無論用Go還是其他語言，避免使用"goto"是大家的共識(shí)。

使用goto會(huì)破壞代碼的自然流程。

會(huì)破壞我們理解不同代碼段之間關(guān)系的方式，讓我們很難在不弄得亂七八糟的情況下修改代碼。

此外，調(diào)試也變得更加令人困惑，測(cè)試也更加棘手。

從本質(zhì)上講，依賴goto往往會(huì)產(chǎn)生更多錯(cuò)誤，并難以深入了解問題。因此，作為最佳實(shí)踐，明智的做法是避開它。

5. 跳過Defer和Recover

如果你忽略"defer"和"recover"，就失去了對(duì)panic的堅(jiān)實(shí)保護(hù)。

為什么?

因?yàn)楫?dāng)出現(xiàn)panic時(shí)，"defer"仍然會(huì)起作用，而"recover"會(huì)抓住panic，讓我們有機(jī)會(huì)處理不可預(yù)見的問題[2]。

看看這個(gè)例子，其中'file.Close()'只是放在末尾，這不是一個(gè)Go風(fēng)格的解決方案:

func readFile(filename string) {
    file, err := os.Open(filename)
    if err != nil {
        panic(err)
    }

    // Do something with the file
    file.Close() // <--- DONT
}

相反，像這樣使用"defer":

func readFile(filename string) {
    file, err := os.Open(filename)
    if err != nil {
        panic(err)
    }
    defer file.Close()
    // Do something with the file
    ...
}

在打開文件后立即調(diào)用defer file.Close()可以確保即使readFile()遇到panic，文件也會(huì)被關(guān)閉。此外，還可以方便的提醒我們?cè)诖蜷_資源后立即進(jìn)行清理。

6. 過多使用context.Background()

Go的context功能非常有用，當(dāng)代碼與數(shù)據(jù)庫或網(wǎng)站對(duì)話時(shí)，有助于管理時(shí)間限制等事情。

如果沒有設(shè)定截止時(shí)間，應(yīng)用可能會(huì)陷入阻塞，被數(shù)以百萬計(jì)的請(qǐng)求淹沒。

通過一個(gè)特殊功能，可以很容易的設(shè)置時(shí)間限制。

該函數(shù)有三種時(shí)間選擇: Fast(0.5秒)、Medium(3秒)和Slow(10秒)。這樣就不用一直使用context.Background()，而且可以為每個(gè)任務(wù)選擇合適的時(shí)間限制。

以下是Fast的一些示例代碼:

const FastTimeout = 500 * time.Millisecond

func WrapCustomContext(ctx context.Context, dur time.Duration) (context.Context, context.CancelFunc) {
  return context.WithTimeout(ctx, dur)
}

func GenFastContext() (context.Context, context.CancelFunc) {
  return WrapCustomContext(context.Background(), FastTimeout)
}

func WrapFastContext(ctx context.Context) (context.Context, context.CancelFunc) {
  return WrapCustomContext(ctx, FastTimeout)
}

有了這些函數(shù)，就可以選擇正確的時(shí)間限制，應(yīng)用也因此運(yùn)行得更好。

好還是不好，只是一些概念，我們可以決定其真正含義。

所以，明智的使用"不好"的特性，它就能變成"最好"的方案。

參考資料：

• [1]5+ BAD Practices In Go: Learn From Mistakes: https://levelup.gitconnected.com/5-bad-practices-in-go-learn-from-mistakes-13afb4d303b3
• [2]What you know about defer in Go is not enough!: https://medium.com/@func25/what-you-know-about-defer-in-go-is-not-enough-2681d4b128c3