（一）背景
大約在兩年之前寫(xiě)過(guò)一篇關(guān)于SwiftLint的文章，時(shí)過(guò)境遷不得不說(shuō)當(dāng)時(shí)的想法還是很粗糙的，但至少也給了自己一個(gè)啟蒙。過(guò)去的一年，公司開(kāi)始自建中心化的CI，也推廣到了各個(gè)團(tuán)隊(duì)中去，參與其中也是獲益匪淺。Lint作為CI中的重要的一環(huán)自然也有不少的價(jià)值輸出，但是隨著日常深入的應(yīng)用還是讓我又思考了一下關(guān)于Lint在公司團(tuán)隊(duì)的實(shí)踐，也算是對(duì)于兩年前那篇文章的補(bǔ)充和拓展吧。
（二）缺陷和痛點(diǎn)
成本，不得不說(shuō)，這是讓人使用SwiftLint的最大障礙。
1.主動(dòng)操作的成本
如果我們直接使用SwiftLint的命令行工具來(lái)進(jìn)行規(guī)范代碼，每次都需要我們主動(dòng)想起“哦~我需要進(jìn)行一次lint”，然后我執(zhí)行了一次“SwiftLint”。對(duì)于人而言，主動(dòng)想起的這個(gè)操作是非常高的。產(chǎn)品開(kāi)發(fā)過(guò)程中我們總說(shuō)客戶很懶，我們開(kāi)發(fā)人員又何嘗不懶呢？
2.構(gòu)建配置文件的成本
如果我們真的使用SwiftLint，它作為一個(gè)工具一定是大而全的，然而落實(shí)到每個(gè)技術(shù)團(tuán)隊(duì)那都是“大清自有國(guó)情在”，幾乎沒(méi)有哪個(gè)項(xiàng)目愿意全量的使用SwiftLint的規(guī)則，大多數(shù)情況之下我們只想要我們自己所需要的規(guī)則。雖然SwiftLint支持
通過(guò)編輯配置文件的方式來(lái)自定義規(guī)則，但是對(duì)于一個(gè)團(tuán)隊(duì)來(lái)說(shuō)往往需要同時(shí)開(kāi)發(fā)多個(gè)工程，倘若每個(gè)工程都需要我們編輯一個(gè)配置文件，這樣機(jī)械的勞動(dòng)想來(lái)是沒(méi)人愿意做的。
3.團(tuán)隊(duì)標(biāo)準(zhǔn)化的成本
在團(tuán)隊(duì)的維度上來(lái)說(shuō)，我們一定是希望大家使用相同的規(guī)范，使得最后提交的代碼不至于五花八門(mén)。但是也由于SwiftLint配置文件的特性，使得我們沒(méi)有辦法通過(guò)現(xiàn)有的方式來(lái)規(guī)范整個(gè)團(tuán)隊(duì)的代碼風(fēng)格規(guī)則。
4.CI的局限
誠(chéng)然CI可以解決一定的問(wèn)題，通過(guò)CI我們可以構(gòu)造出一套標(biāo)準(zhǔn)的流程，通過(guò)統(tǒng)一的標(biāo)準(zhǔn)來(lái)對(duì)每一個(gè)MR/PR中的代碼進(jìn)行l(wèi)int校驗(yàn)。然而可惜的是，CI也存在自己的局限性，首先無(wú)論怎么通知，這里還是存在人的主動(dòng)性問(wèn)題，即便是通過(guò)釘釘或者郵件通知了當(dāng)事人本次的提交存在哪些問(wèn)題，但是由于人的“惰性”，很可能就會(huì)忽略了本次的警告。而且，CI的操作必須在commit之后，即便你是一個(gè)自驅(qū)力極強(qiáng)的人，每次CI報(bào)告的規(guī)則違反你都會(huì)認(rèn)真修改，但是太多的code style fixed還是會(huì)污染整個(gè)git日志。所以CI的延遲性，也是一個(gè)無(wú)法忽視的弊端。
（三）團(tuán)隊(duì)實(shí)踐：SafeCommit
針對(duì)以上的缺陷，我們團(tuán)隊(duì)打算構(gòu)建一個(gè)SafeCommit工具，在我們的計(jì)劃中，不光是代碼的校驗(yàn)，我們希望把commit的校驗(yàn)也一并做進(jìn)去，統(tǒng)一化團(tuán)隊(duì)的commit風(fēng)格。
每當(dāng)我們需要git commit的時(shí)候，我們通過(guò)git sc替代。此時(shí)SafeCommit會(huì)對(duì)被添加的文件進(jìn)行l(wèi)int，如果是swift源文件那么就進(jìn)行lint操作，否則跳過(guò)。如果發(fā)現(xiàn)當(dāng)前的文件沒(méi)有通過(guò)lint，那么就把結(jié)果輸出到窗口。
lint通過(guò)之后，工具會(huì)提示用戶選擇一個(gè)commit的類型，然后輸入本次的commit的內(nèi)容，這樣的好處是簡(jiǎn)化了高頻的git commit -m 'xxxxxxx'，同時(shí)也是格式化commit的message，當(dāng)查看git log的時(shí)候?qū)?huì)非常的工整。
輸入了commit的內(nèi)容之后，本次的提交也就結(jié)束了。
哦~對(duì)了，也是支持SourceTree等GUI工具。
（四）SafeCommit所解決的問(wèn)題
被動(dòng)性
由于SafeCommit是通過(guò)git hook實(shí)現(xiàn)的，所以從原來(lái)的工程師自己主動(dòng)調(diào)用lint的操作變成了提交時(shí)的被動(dòng)lint，也算是極大的照顧了工程師們“懶惰”的天性。同時(shí)，也是因?yàn)橥ㄟ^(guò)git hook實(shí)現(xiàn)，即便之后不使用git sc來(lái)進(jìn)行提交，而通過(guò)git commit的原生命令來(lái)提交，也一樣會(huì)觸發(fā)代碼以及提交信息的lint（當(dāng)然這一切的前提是你至少在這個(gè)git倉(cāng)庫(kù)下運(yùn)行過(guò)一次git sc）。
低成本&低侵入
SafeCommit默認(rèn)不會(huì)對(duì)您的倉(cāng)庫(kù)做任何的修改，我們也再也不需要煩人的YML配置文件了。我們只需要通過(guò)npm來(lái)安裝SafeCommit，我們就可以在所有的Swift工程下使用它，比起官方README中提到的使用命令行和在build phase里嵌入腳本實(shí)在是方便太多。
還有一個(gè)減輕成本的地方是，每次提交我們只會(huì)對(duì)進(jìn)行了git add操作的文件進(jìn)行lint。這樣的好處是，一來(lái)不會(huì)大規(guī)模的lint造成每次提交緩慢的問(wèn)題，二來(lái)也對(duì)沒(méi)有接入過(guò)lint的老項(xiàng)目更加的友好，不至于些許的修改就報(bào)出大量的警告。
規(guī)范化&普適性
由于使用的是統(tǒng)一的SafeCommit，所以對(duì)于團(tuán)隊(duì)的代碼風(fēng)格統(tǒng)一也是簡(jiǎn)單了許多，只需要配置一份（當(dāng)然對(duì)于大多數(shù)團(tuán)隊(duì)來(lái)說(shuō)直接使用默認(rèn)的配置，就可以做到開(kāi)箱即用）配置文件，就可以在所有的Swift項(xiàng)目下使用。SafeCommit也不強(qiáng)依賴其他的IDE，只要你的工程是通過(guò)git來(lái)進(jìn)行版本控制的，那么就可以使用SafeCommit。順帶一提，由于SafeCommit的普世的設(shè)計(jì)，同時(shí)也支持Java CheckStyle，如果需要其他的語(yǔ)言支持也可以拓展。
（五）SafeCommit沒(méi)有解決的問(wèn)題
針對(duì)于iOS開(kāi)發(fā)，如果想要實(shí)現(xiàn)eslint在vs code上的即時(shí)性表現(xiàn)，暫時(shí)沒(méi)有什么太好的辦法，即便是SwiftLint官方所說(shuō)的build phase也是需要build才能展示，這樣尷尬的處境可能只能等蘋(píng)果官方的Xcode新特性了吧。
（六）簡(jiǎn)潔和規(guī)范的意義
大概從上學(xué)的時(shí)候就能看到人和人的差別，他們字跡未必好看但下筆一定工整，一筆一劃處處用心。本來(lái)工整的行文和整齊的排布并不能多得兩分，但這份嚴(yán)謹(jǐn)?shù)慕橙藨B(tài)度一再讓我嘆服。
優(yōu)秀是一種習(xí)慣，最后附上一張愛(ài)因斯坦的手稿作為結(jié)尾，與君共勉。
