Go常見錯誤和不良實踐

Go編程的某些實踐容易被誤用或忽視，了解這些特性的特點和陷阱，可以幫助我們編寫更好的代碼。原文: 5+ BAD Practices In Go: Learn From Mistakes[1]

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

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

1. 使用init()

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

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

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

// package A
func init() {}
// package B 
func init() {}
// which run first?

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

使用init()的另一個缺點是測試會變得復(fù)雜。因為這些函數(shù)是自動運行的，無法選擇何時執(zhí)行。

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

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

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

2. 使用全局變量

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

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

競爭條件: 當有多個程序試圖同時訪問同一個全局變量時，事情可能會變得混亂。

更少的可測試性: 應(yīng)用程序依賴于全局變量，意味著有狀態(tài)，從而在單元或集成測試期間，這些全局變量需要與main()函數(shù)中的內(nèi)容或在生產(chǎn)環(huán)境中部署的內(nèi)容保持一致。

模塊化程度較低，可重用性較差: 可以從任何地方訪問全局變量，很難跟蹤其使用方式和位置。

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

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

3. 忽略錯誤信息

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

"忽略錯誤真的那么糟糕嗎?"

是的，完全正確。

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

如果不對錯誤進行管理，也許程序會出現(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)
}

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

4. 避免GOTO

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

使用goto會破壞代碼的自然流程。

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

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

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

5. 跳過Defer和Recover

如果你忽略"defer"和"recover"，就失去了對panic的堅實保護。

為什么?

因為當出現(xiàn)panic時，"defer"仍然會起作用，而"recover"會抓住panic，讓我們有機會處理不可預(yù)見的問題[2]。

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

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，文件也會被關(guān)閉。此外，還可以方便的提醒我們在打開資源后立即進行清理。

6. 過多使用context.Background()

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

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

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

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

以下是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ù)，就可以選擇正確的時間限制，應(yīng)用也因此運行得更好。

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

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

參考資料

[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 

以上就是Go編程中常見錯誤和不良實踐解析的詳細內(nèi)容，更多關(guān)于Go錯誤解析的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論