如何保障Go語言基礎代碼質量？

爲何要談這個topic？

實踐中，質量保障體系的建設，主要針對兩個目標: 一是不斷提升目標業務測試覆蓋率，保障面向客戶的產品質量；二就是儘量的提升人效，加強迭代效率。而構建全鏈路質量卡點就是整個體系建設的核心手段。筆者用下圖來描述這整個鏈路:

能夠看到，雖然保障業務迭代的方向性正確排在最前面，但在具體操做上，這一步須要的是強化流程規範和構建企業文化，同時對各負責人技能培訓，能夠說多數是軟技能。而保障基礎代碼質量環節發力於自動化建設鏈路之始，是能夠經過技術手段來消滅潛在的質量問題，因此構建好的話能極大的下降心智負擔，很是值得關注。

咱們都知道，代碼的好壞會直接影響到業務質量，團隊協做，以及後期技術債等。有一個經典的圖來描述代碼質量的好壞，當能深切表達程序員的心裏:

而同時咱們相信，絕大部分程序員都有追求卓越的初心，且會盡量的在本身能力範圍內編寫高質量的代碼。

可是，保障基礎代碼質量光靠程序員的我的素質必定是不全面，是人就會犯錯，可能會疏忽。咱們最須要的是一種自動化的機制來持續確保不出問題。這也是自動化的魅力，一次構建，持續收穫價值。

此類工具在業界通常叫linter，不一樣的語言有不一樣的實現。本文主要探究Go語言相關的。
在介紹相關工具以前，咱們先看看幾個經典的代碼壞味道:

這段代碼常規運行不會有問題，可是在一些場景下循環執行，那可能就會有問題了, 咱們來看看:

(注:ex2是上述代碼編譯出的可執行文件名字)

很明顯，有句柄泄露。緣由也很簡單，http response的body沒有關閉。但這個關閉語句，一不注意也容易寫錯：

這時候若是百度掛了，上述程序程序就會由於空指針引用，形成非預期的panic，很是的不優雅。因此正確的作法應該是在err判斷以後再行關閉body(關於Client.Do 具體的各類限制，你們能夠參考這裏: https://golang.org/pkg/net/http/#Client.Do)

如此種種，此類小問題在實際編碼活動中很是常見，且不容易一眼看出問題。甚至常規的測試可能也難檢測出來，可謂很是棘手。好在Go語言的開發者們爲咱們想到了這一點，內置工具鏈中的vet命令，就能方便的檢測到不少相似的問題。

還好比下面的代碼場景，我在實際的測試用例和業務代碼都看到過：

go vet 能夠很容易檢測出這個問題(其餘vet功能，能夠參考這裏: https://golang.org/cmd/vet/)。

go的工具鏈中，還有一個不得不提，那就是大名鼎鼎的go fmt，其了卻了其餘語言常常陷入的代碼風格之爭，是Go語言生態構建很是巧妙的地方。另外golint也是google主推的go語言代碼代碼風格工具，雖非強制，但強烈建議新項目適用。

Go linters業界現狀

上面主要說到Go工具鏈的內置工具，還有一些非官方的工具也比較有名，好比 staticcheck, errcheck在github上Star都較多。此類工具備個專門的的github庫，收集的比較全，參見 awesone-static-analysis

同時還有些項目旨在聚合此類工具，提供更方便的使用方式，以及一些酷炫的產品化。好比golangci-lint, 其衍生的商業化項目，能夠自動針對github PR作代碼審覈，對有問題的地方自動comments，比較有意思。

如何才能優雅的落地linter檢查？

linter工具必須爲產品質量服務，否則就是作無用功。實踐中，咱們應該思考的是如何才能優雅的落地linter檢查，如何才能創建有效的質量卡點。

推薦針對PR，作代碼檢查，保障入庫代碼質量。基於PR作事情是我比較看好的，由於這是調動全部研發力量，自然契合的地方。且進一步講，這也是測試基礎設施更能體現價值的地方。

目前Github上有不少這方面的集成系統作的都比較好，可以快速的幫咱們落地PR測的檢查，好比Travis, Circle CI等。另外就是著名的Kubernetes社區，也自行構建了強大的Prow系統，其不光是基於CICD系統，還構建了chat ops模式，爲參與Kubernetes的社區的貢獻者提供了方便。

細看Kubernetes庫，會發現，其會針對每一個PR都作以下靜態檢查:

• gofmt： https://github.com/kubernetes/kubernetes/blob/master/hack/verify-gofmt.sh
• govet: https://github.com/kubernetes/kubernetes/blob/master/hack/make-rules/vet.sh
• golint: https://github.com/kubernetes/kubernetes/blob/master/hack/verify-golint.sh
  由於golint只是糾正代碼風格，並非強制，因此k8s官方就弄了比較軟的方案，對於當前已經存在的代碼若是有問題，先排除掉(以下)。對於新生代碼，若是檢查失敗，ci就掛掉。
  https://github.com/kubernetes/kubernetes/blob/master/hack/.golint_failures

Kubernetes只利用了官方的幾款工具, 在檢測準確性上比較有保障。有了這些檢查點，也能倒逼研發人員關注提交代碼的質量，會迫使其在本地或者IDE上就配置好檢查，確保每次提交的PR都能經過檢查，不浪費CI資源。這也是合格工程師的基本要求。

總結

高質量的代碼是業務質量保障的基礎。而編寫高質量的代碼是技術問題，同時也應該是企業文化問題。由於當你們都開始注重技術，注重代碼質量時，天然會朝着精益求精的路上行進，視糟糕的代碼爲仇寇。

個人一位老闆跟我說過，要作就作Number One。而在沒達到第一的時候，那就要向業界標杆看齊，好比Netflix，Google，Facebook等。當你們都很是注重本身代碼質量時，工程師纔有時間去關注解決更加系統性的問題，而不用一直在Low Level徘徊。筆者深覺得然。

Contact me?

Email: jinsdu@outlook.com

Blog: http://www.cnblogs.com/jinsdu/

Github: https://github.com/CarlJi