（一）背景
大約在兩年之前寫過一篇關於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新特性了吧。
（六）簡潔和規範的意義
大概從上學的時候就能看到人和人的差別，他們字跡未必好看但下筆一定工整，一筆一劃處處用心。本來工整的行文和整齊的排布並不能多得兩分，但這份嚴謹的匠人態度一再讓我歎服。
優秀是一種習慣，最後附上一張愛因斯坦的手稿作為結尾，與君共勉。
