012-基於 git hooks 的前端代碼質量控制解決方案

原文看這裏：https://github.com/kuitos/kui...
所有文章看這裏 https://github.com/kuitos/kui...

國際慣例先說下故事背景

一般狀況下，若是咱們是一個對代碼質量有要求或者存在code review這一流程的團隊，咱們必然會有一套團隊內部達成共識的code style從而提升項目的可維護性及代碼的可讀性。而確保提交到代碼倉庫的代碼是符合規範的手段一般是，代碼提交前由工具幫忙指出，如早期的jslint、jshint以及如今的eslint。提交後code review階段由其餘同窗確保代碼沒有其餘規範及質量問題。

目前這種方式的癥結點

1. 整個流程全靠團隊成員自覺遵照。也就是說，即便咱們在coding以前已經有一份code style放在那，並且eslint(jslint、jshint)工具已經配置好，依然有可能存在漏看了(或者根本沒看。。)工具的提示信息、忘記了部分規範要求而直接把代碼提交的狀況。

2. code review階段reviewer常常要指出一些純代碼風格上的問題價值過低。由於上一條中出現的狀況，reviewer還得花一些時間去指出純代碼風格上的問題，這種事情價值過低並且每每會讓reviewer感到有心無力若是ta恰好仍是個強迫症患者的話?。

3. 總之純靠人肉去確保代碼規範是一件價值很低並且很靠不住的事情。

解決思路

既然人肉靠不住那咱們只能讓整個流程自動化讓工具替咱們完成代碼規範檢查的事情。我能想到的大概有這幾種方式。

1. 配置代碼質量工具每次代碼提交以前跑一下，而後針對工具給出的信息調整。

2. 配置代碼質量工具reviewer每次review以前跑一下，檢查有沒有基本的規範問題。

3. 依靠CI(持續集成工具)對每次提交的代碼作code check，每次接收push以前跑一下code check，若是沒有經過直接拒絕接收push。

一、2兩種方式都是經過工具方式下降了人肉檢查代碼規範的工做量，不過本質仍是人肉。。 
3方式再也不人肉了可是依賴外部系統去作會存在風險及成本，好比哪天CI工具由bamboo切到了jenkins 而後又切到travis。。

直到有一天在下在fork了github上的一個項目並對其作了必定改造而後自信滿滿地準備提交代碼的時候(json-mock-server)，git一直在報錯代碼始終push不上去，報錯信息也看不出什麼東西，不行只能請教了對git比較內行的同事@arzyu，猜想是git hooks上配置了什麼鉤子腳本(後來證明是單元測試沒覆蓋到位)，嘗試把項目路徑下的.git文件夾刪除以後，終於能正常提交了?

這件事給了我一個新的思路，就是咱們能不能基於git的hook功能來作這這種自動化的事情呢？恰好在下又會一點點shell?

因此理想的方式是

咱們在git hooks裏配置各類預處理腳本，好比代碼檢查或者跑單元測試之類的事情，若是咱們的代碼沒有經過代碼檢查或者測試用例覆蓋率不夠，咱們的push甚至commit會直接被拒絕。

好東西啊這不就是我這種極端分子想要的麼哈哈！

怎麼作

首先介紹一下git hooks是什麼吧

鉤子(hooks)是一些在"$GIT-DIR/hooks"目錄的腳本, 在被特定的事件(certain points)觸發後被調用。當"git init"命令被調用後, 一些很是有用的示例鉤子文件(hooks)被拷到新倉庫的hooks目錄中; 可是在默認狀況下這些鉤子(hooks)是不生效的。 把這些鉤子文件(hooks)的".sample"文件名後綴去掉就可使它們生效了。

也就是在咱們的git倉庫下會有一個.git配置文件夾，它裏面包含git操做相關的一系列 預處理／後處理 腳本。如 pre-commit、post-push之類的。

在一番google研究以後發現這事情操做起來並無想象中那麼簡單，好比咱們在什麼時機將本身的腳本插入到hooks裏，讓使用者手動調命令這種主動式的方式一直不是我推崇的(要把調用者想象成懶癌晚期)，而後處理腳本怎麼寫寫哪裏也沒想到合適方式，一度放棄。

後來忽然想起，以前那個開源項目是怎麼作的？它是怎麼把預處理腳本偷偷摸摸插入到hooks裏的？？因而突發奇想去研究別人的項目。

結果發現做者本身寫了一個插件husky，專門用來處理這種git提交時的自動化處理。

大體用法像這樣：

// 根目錄package.json
"scripts": { "codecheck": "NODE_ENV=test eslint src/**/*.js", "test": "BABEL_JEST_STAGE=0 jest --verbose --watch", "precommit": "npm run codecheck && npm test" }

配置了precommit以後每次代碼提交以前git都會自動去跑代碼檢查及單元測試任務，都跑經過以後才能提交成功。更多用法請看項目主頁husky

插件實現的機制大體是，在你install該插件時，它會自動往git hooks裏埋入不少相應的鉤子腳本(git hook能識別的)，這些鉤子函數會去讀區package.json中的配置信息，當用戶作某些git操做觸發相應鉤子時會天然去調用配置好的任務，從而實現咱們的自動化需求，包括代碼檢查跟單元測試驗證以及更多的自動化任務。

拓展思考

基於npm對install動做的鉤子接口，咱們能夠提供一個插件，當使用者install該插件時插件會幫助用戶作一系列初始化構建工做。開發時各業務模塊獨立倉庫開發，上線或測試時提供構建插件一行install命令把全部業務模塊組合起來變成一個完整的項目。具體打包、發佈的方式後面會寫一篇關於前端工程化的blog來介紹。