聊聊SwiftLint在團隊的實踐

（一）背景

大約在兩年以前寫過一篇關於SwiftLint的文章，時過境遷不得不說當時的想法仍是很粗糙的，但至少也給了本身一個啓蒙。過去的一年，公司開始自建中心化的CI，也推廣到了各個團隊中去，參與其中也是獲益匪淺。Lint做爲CI中的重要的一環天然也有很多的價值輸出，可是隨着平常深刻的應用仍是讓我又思考了一下關於Lint在公司團隊的實踐，也算是對於兩年前那篇文章的補充和拓展吧。

（二）缺陷和痛點

成本，不得不說，這是讓人使用SwiftLint的最大障礙。

1.主動操做的成本

若是咱們直接使用SwiftLint的命令行工具來進行規範代碼，每次都須要咱們主動想起「哦~我須要進行一次lint」，而後我執行了一次「SwiftLint」。對於人而言，主動想起的這個操做是很是高的。產品開發過程當中咱們總說客戶很懶，咱們開發人員又未嘗不懶呢？

2.構建配置文件的成本

若是咱們真的使用SwiftLint，它做爲一個工具必定是大而全的，然而落實到每一個技術團隊那都是「大清自有國情在」，幾乎沒有哪一個項目願意全量的使用SwiftLint的規則，大多數狀況之下咱們只想要咱們本身所須要的規則。雖然SwiftLint支持 經過編輯配置文件的方式來自定義規則，可是對於一個團隊來講每每須要同時開發多個工程，假若每一個工程都須要咱們編輯一個配置文件，這樣機械的勞動想來是沒人願意作的。

3.團隊標準化的成本

在團隊的維度上來講，咱們必定是但願你們使用相同的規範，使得最後提交的代碼不至於五花八門。可是也因爲SwiftLint配置文件的特性，使得咱們沒有辦法經過現有的方式來規範整個團隊的代碼風格規則。

4.CI的侷限

誠然CI能夠解決必定的問題，經過CI咱們能夠構造出一套標準的流程，經過統一的標準來對每個MR/PR中的代碼進行lint校驗。然而惋惜的是，CI也存在本身的侷限性，首先不管怎麼通知，這裏仍是存在人的主動性問題，即使是經過釘釘或者郵件通知了當事人本次的提交存在哪些問題，可是因爲人的「惰性」，極可能就會忽略了本次的警告。並且，CI的操做必須在commit以後，即使你是一個自驅力極強的人，每次CI報告的規則違反你都會認真修改，可是太多的code style fixed仍是會污染整個git日誌。因此CI的延遲性，也是一個沒法忽視的弊端。

（三）團隊實踐：SafeCommit

針對以上的缺陷，咱們團隊打算構建一個SafeCommit工具，在咱們的計劃中，不光是代碼的校驗，咱們但願把commit的校驗也一併作進去，統一化團隊的commit風格。

每當咱們須要git commit的時候，咱們經過git sc替代。此時SafeCommit會對被添加的文件進行lint，若是是swift源文件那麼就進行lint操做，不然跳過。若是發現當前的文件沒有經過lint，那麼就把結果輸出到窗口。

lint經過以後，工具會提示用戶選擇一個commit的類型，而後輸入本次的commit的內容，這樣的好處是簡化了高頻的git commit -m 'xxxxxxx'，同時也是格式化commit的message，當查看git log的時候將會很是的工整。

輸入了commit的內容以後，本次的提交也就結束了。

哦~對了，也是支持SourceTree等GUI工具。

（四）SafeCommit所解決的問題

被動性

因爲SafeCommit是經過git hook實現的，因此從原來的工程師本身主動調用lint的操做變成了提交時的被動lint，也算是極大的照顧了工程師們「懶惰」的天性。同時，也是由於經過git hook實現，即使以後不使用git sc來進行提交，而經過git commit的原生命令來提交，也同樣會觸發代碼以及提交信息的lint（固然這一切的前提是你至少在這個git倉庫下運行過一次git sc）。

低成本&低侵入

SafeCommit默認不會對您的倉庫作任何的修改，咱們也不再須要煩人的YML配置文件了。咱們只須要經過npm來安裝SafeCommit，咱們就能夠在全部的Swift工程下使用它，比起官方README中提到的使用命令行和在build phase裏嵌入腳本實在是方便太多。

還有一個減輕成本的地方是，每次提交咱們只會對進行了git add操做的文件進行lint。這樣的好處是，一來不會大規模的lint形成每次提交緩慢的問題，二來也對沒有接入過lint的老項目更加的友好，不至於些許的修改就報出大量的警告。

規範化&普適性

因爲使用的是統一的SafeCommit，因此對於團隊的代碼風格統一也是簡單了許多，只須要配置一份（固然對於大多數團隊來講直接使用默認的配置，就能夠作到開箱即用）配置文件，就能夠在全部的Swift項目下使用。SafeCommit也不強依賴其餘的IDE，只要你的工程是經過git來進行版本控制的，那麼就可使用SafeCommit。順帶一提，因爲SafeCommit的普世的設計，同時也支持Java CheckStyle，若是須要其餘的語言支持也能夠拓展。

（五）SafeCommit沒有解決的問題

針對於iOS開發，若是想要實現eslint在vs code上的即時性表現，暫時沒有什麼太好的辦法，即使是SwiftLint官方所說的build phase也是須要build才能展現，這樣尷尬的處境可能只能等蘋果官方的Xcode新特性了吧。

（六）簡潔和規範的意義

大概從上學的時候就能看到人和人的差異，他們字跡未必好看但下筆必定工整，一筆一劃到處用心。原本工整的行文和整齊的排布並不能多得兩分，但這份嚴謹的匠人態度一再讓我歎服。

優秀是一種習慣，最後附上一張愛因斯坦的手稿做爲結尾，與君共勉。