摸魚心法第一章——和配置文件說拜拜
為了能摸魚我們團隊做了容器化，但是帶來的問題是服務配置文件很麻煩，然后大家在群里進行了“親切友好”的溝通圖片圖片圖片圖片對比就對比，簡單對比下獨立配置中心和k8s作為配
使用Go和使用其他編程語言中一樣，需要了解常見錯誤和不良實踐，才能編寫既干凈又高效的代碼。
本文討論的一些實踐并不一定都是不好的，在特定情況下很有用。 然而，我們需要知道可能會有什么問題，為什么應該回避某些習慣，以及如何避開常見的陷阱。
Go中的init()函數(shù)是一個特殊函數(shù)，在main函數(shù)之前執(zhí)行。
"如果初始化對于任何包都很重要，為什么init()在Go中被認為是一個不好的做法?"
是的，雖然init()函數(shù)確實有助于在運行核心邏輯之前進行初始化，但其執(zhí)行順序可能很難理解，可能導致對初始化順序的混淆。
// package Afunc init() {}// package B func init() {}// which run first?想象一下，有兩個模塊在安裝時相互依賴，但位于不同的包中。結果我們最終需要編寫更復雜的代碼來管理時序，更糟的是，甚至可能陷入死鎖情況。
使用init()的另一個缺點是測試會變得復雜。因為這些函數(shù)是自動運行的，無法選擇何時執(zhí)行。
缺乏控制使得設置測試用例成為一項挑戰(zhàn)。
我曾經(jīng)遇到過一個問題，我的服務在部署后花了很長時間才準備好。我在main()函數(shù)的開始處設置了一個斷點，但從未觸發(fā)。
經(jīng)過冗長的調(diào)試后，我們發(fā)現(xiàn)一個成員使用了某個包中的init()函數(shù)從一個大文件加載一個大數(shù)據(jù)集，這讓我們花費大量時間去解決這么一個小問題。
Go中的全局變量可能會帶來類似單例的問題，特別是當這些全局變量很復雜時(比如映射、切片或指針)。
"那么，全局變量有什么大不了的?"
因此，這里的建議是保持對包的封裝。
從而使得代碼更容易移動，并且不太可能破壞其他東西。通過避免使用全局變量，可以使代碼不那么受約束，并且更容易更新或復用。
用Go編程時，錯誤是不可避免的，知道如何處理錯誤可以讓我們避免各種各樣的問題。
"忽略錯誤真的那么糟糕嗎?"
是的，完全正確。
一些Go新手可能會用"_"符號將錯誤撇在一邊，但忽略函數(shù)返回的錯誤值，可能會帶來麻煩。
如果不對錯誤進行管理，也許程序會出現(xiàn)panic和crash。
// sample 1func main() { var x interface{} = "hello" s := x.(int) // panic: interface conversion: interface {} is string, not int fmt.Println(s)}// sample 2func main() { var x interface{} = "hello" s, _ := x.(int) // safe but DON'T fmt.Println(s)}跳過錯誤可能會適得其反，尤其是對于線上生產(chǎn)環(huán)境，調(diào)試會成為一場噩夢。總是--我的意思是總是--檢查錯誤并采取正確的措施以保持代碼順利運行。
無論用Go還是其他語言，避免使用"goto"是大家的共識。
使用goto會破壞代碼的自然流程。
會破壞我們理解不同代碼段之間關系的方式，讓我們很難在不弄得亂七八糟的情況下修改代碼。
此外，調(diào)試也變得更加令人困惑，測試也更加棘手。
從本質(zhì)上講，依賴goto往往會產(chǎn)生更多錯誤，并難以深入了解問題。因此，作為最佳實踐，明智的做法是避開它。
如果你忽略"defer"和"recover"，就失去了對panic的堅實保護。
為什么?
因為當出現(xiàn)panic時，"defer"仍然會起作用，而"recover"會抓住panic，讓我們有機會處理不可預見的問題[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，文件也會被關閉。此外，還可以方便的提醒我們在打開資源后立即進行清理。
Go的context功能非常有用，當代碼與數(shù)據(jù)庫或網(wǎng)站對話時，有助于管理時間限制等事情。
如果沒有設定截止時間，應用可能會陷入阻塞，被數(shù)以百萬計的請求淹沒。
通過一個特殊功能，可以很容易的設置時間限制。
該函數(shù)有三種時間選擇: Fast(0.5秒)、Medium(3秒)和Slow(10秒)。這樣就不用一直使用context.Background()，而且可以為每個任務選擇合適的時間限制。
以下是Fast的一些示例代碼:
const FastTimeout = 500 * time.Millisecondfunc 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ù)，就可以選擇正確的時間限制，應用也因此運行得更好。
好還是不好，只是一些概念，我們可以決定其真正含義。
所以，明智的使用"不好"的特性，它就能變成"最好"的方案。
參考資料：
本文鏈接：http://www.www897cc.com/showinfo-26-60943-0.html從錯誤中學習: 了解Go編程的六個壞習慣
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 為啥我放棄用 Pinia 和 Vuex 去做字典狀態(tài)管理呢？
下一篇： 快速初始化容器化Gin項目
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號