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