3種常見的代碼規範類型

從事web開發已有7個年頭，經歷過幾個團隊和很多項目，也面試過一些開發者。 發現不一樣公司對代碼規範這一塊的要求相差很大，有的公司甚至沒有規範。 究其原因，無非是項目緊張，沒有時間整理。 長此以往，隨着項目不斷變大，維護變得困難，各類問題暴露出來：代碼可讀性差、修改容易出bug、邏輯混亂。。。 因此在技術上稍有追求的團隊都意識到規範的重要性。

代碼規範的意義

先思考一個問題：什麼是好的代碼？

你可能給出不少意見，好比：

• 少用全局變量。
• 高內聚，低耦合。
• 遵循單一原則。
• 擁有註釋說明。
• 。。。

站在開發者我的層面來思考問題，全部這些「獨善其身」的道理都正確。 但若是更進一步，站在團隊的角度，考慮到維護代碼的開發者會不斷地變動；加入時間維度，考慮到代碼會不斷地被修改。

什麼樣的代碼纔是好代碼？

曾經看到有位做者說「風格一致」的代碼就是好代碼，即團隊全部人寫出來的代碼就像是一我的所寫的。這個觀點我很是贊同。

有的讀者可能會反駁，代碼寫得同樣就是好嗎？要是團隊成員水平很低，寫得代碼都很爛呢？

首先，若是團隊成員水平都很低，那麼寫出來的代碼不會是「風格一致」，而會是「風格迥異」。 回想本身最初編程的時候是否是常常在網上搜索代碼，而後直接賦值粘貼再改改，發現能用就以爲OK了？ 這種質量的代碼不只成員之間寫的代碼具備風格差別，就連同一個開發者寫的代碼也會有所不一樣。

「風格一致」背後的意義是什麼？

如今的開發工做被不斷分化，前端、後端、交互設計師、產品經理。。。 這符合英國經濟學家亞當斯密在《國富論》中提出的「分工帶來效率」，可是帶來的最大問題就是溝通（這裏的「溝通」指信息的交流方式）成本上升，例如前端和設計師溝通可能經過psd文件，和後端溝通會經過API。

因此會有REST API設計風格，會有GraphQL。本質上都是在造成共識，下降溝通成本。「風格一致」的代碼規範的做用就和它們同樣，旨在下降開發者因寫做風格差別而帶來的維護成本。由於代碼雖然是運行在機器上，但終究仍是給人看的。

爲了造成好的代碼規範，都有哪些方式？

看不見的規範

看不見的規範指的就是「靠人規範」。 這是最簡單粗暴的方式，依賴開發者我的經驗來指點入職新人進行代碼編寫，或者依靠偶爾進行的代碼分享和評審。 全部的代碼規範都在開發者腦殼裏，基本靠語言傳遞。 這種靠「口口相傳」的開發規範，對於學習者來講由於無文檔可查，全憑我的記憶。 因此根據我的經驗不一樣、記憶力不一樣，不一樣的開發者會有不一樣的規範，難以保證代碼風格一致。

看得見的規範

不少團隊都會用編寫各類規範文檔。 百度、谷歌上隨手一搜「開發規範」，能夠找到大量的文章。 這種方式解決了規範執行依賴「老員工靠經驗，新員工靠記憶」的問題，由於造成了文字，一方面能夠修訂，一方面能夠查看。 可是文檔終究只是文檔，即便文檔寫得再好，但代碼仍是可能寫得一團糟。 執行效果的保障成了新的問題~

無處不在的規範

在這種狀況下代碼檢驗工具應運而生，開發者能夠把編碼規範寫成配置文件，再配合工具對代碼進行檢驗。 同時在開發環境中使用插件來實時提示開發者遵照校驗規則。 即便開發者提交了不符合規範的代碼，也能夠在部署以前用多種方式阻止代碼部署，好比利用git的鉤子程序或者在持續集成中進行檢驗。 這種方式很具備工程思惟，能合理利用工具解決問題，這樣的代碼已經基本具備「風格一致」的特色了。但校驗工具的做用也是有限的，沒法理解代碼語義。

理想的代碼規範

既然這些都不完美，到底有沒有更好的解決方案？

沒有~也有~

確實沒有找到一勞永逸的工具或方法，可是值得慶幸的是咱們能夠把他們結合起來：使用靜態校驗工具來規範代碼的基本書寫規範，而後對於校驗工具沒法完成的規範寫成文檔，最後經過代碼合併時的代碼審查進行保障。

例如我爲如今前端項目的規範就包括多種形式：

• 對於腳本語言TypeScript和預處理語言Sass，直接省略了規範文檔，採用的是使用對應的校驗工具tslint和sasslint，編輯器集成的插件能夠及時提醒開發者遵循規範，對於有疑問的錯誤信息也很容易在網上進行查找。
• 對於比較靈活的部分，如變量命名、文件建立以及代碼內容則採用文檔描述加上代碼評審的方式，評審方式爲互評，先由其它開發者查閱代碼進行評論，而後再轉給管理員進行審覈。

固然這種方式在初期的磨合成本是會略高一些，好比校驗規則沒有文檔說明，評審耗費時間等。可是隨着開發不斷進行，這種成本會不斷下降到趨近於0，由於代碼寫的越多對規範越熟悉，評審改進次數越多也能促進團隊在編碼上達成共識。同時在代碼達成一致以後這些同事也能夠爲新加入團隊的同事提供指導和幫助。從經濟學的角度來講，就是邊際成本遞減和收益遞增。

最後

懂得避免的問題賽過懂得解決問題，好的規範能避免寫出糟糕的代碼，爲之後節省大量重構、修復bug的時間。