從事web開發已有7個年頭，經歷過幾個團隊和不少項目，也面試過一些開發者。
發現不同公司對代碼規範這一塊的要求相差很大，有的公司甚至沒有規範。
究其緣由，無非是項目緊張，沒有時間整理。
久而久之，隨著項目不斷變大，維護變得困難，各種問題暴露出來：代碼可讀性差、修改容易出bug、邏輯混亂。。。
所以在技術上稍有追求的團隊都意識到規範的重要性。
代碼規範的意義
先思考一個問題：什麼是好的代碼？
你可能給出很多意見，比如：
- 少用全局變量。
- 高內聚，低耦合。
- 遵循單一原則。
- 擁有註釋說明。
- 。。。
站在開發者個人層面來思考問題，所有這些“獨善其身”的道理都正確。
但如果更進一步，站在團隊的角度，考慮到維護代碼的開發者會不斷地變更；加入時間維度，考慮到代碼會不斷地被修改。
什麼樣的代碼才是好代碼？
曾經看到有位作者說“風格一致”的代碼就是好代碼，即團隊所有人寫出來的代碼就像是一個人所寫的。這個觀點我非常贊同。
有的讀者可能會反駁，代碼寫得一樣就是好嗎？要是團隊成員水平很低，寫得代碼都很爛呢？
首先，如果團隊成員水平都很低，那麼寫出來的代碼不會是“風格一致”，而會是“風格迥異”。
回想自己最初編程的時候是不是經常在網上搜索代碼，然後直接賦值粘貼再改改，發現能用就覺得OK了？
這種質量的代碼不僅成員之間寫的代碼具有風格差異，就連同一個開發者寫的代碼也會有所不同。
“風格一致”背後的意義是什麼？
現在的開發工作被不斷分化，前端、後端、交互設計師、產品經理。。。
這符合英國經濟學家亞當斯密在《國富論》中提出的“分工帶來效率”，但是帶來的最大問題就是溝通（這裡的“溝通”指信息的交流方式）成本上升，例如前端和設計師溝通可能通過psd文件，和後端溝通會通過API。
所以會有REST API設計風格，會有GraphQL。本質上都是在形成共識，降低溝通成本。“風格一致”的代碼規範的作用就和它們一樣，旨在降低開發者因寫作風格差異而帶來的維護成本。因為代碼雖然是運行在機器上，但終究還是給人看的。
為了形成好的代碼規範，都有哪些方式？
看不見的規範
看不見的規範指的就是“靠人規範”。
這是最簡單粗暴的方式，依賴開發者個人經驗來指點入職新人進行代碼編寫，或者依靠偶爾進行的代碼分享和評審。
所有的代碼規範都在開發者腦袋裡，基本靠語言傳遞。
這種靠“口口相傳”的開發規範，對於學習者來說因為無文檔可查，全憑個人記憶。
所以根據個人經驗不同、記憶力不同，不同的開發者會有不同的規範，難以保證代碼風格一致。
看得見的規範
很多團隊都會用編寫各種規範文檔。
百度、谷歌上隨手一搜“開發規範”，可以找到大量的文章。
這種方式解決了規範執行依賴“老員工靠經驗，新員工靠記憶”的問題，因為形成了文字，一方面可以修訂，一方面可以查看。
但是文檔終究只是文檔，即使文檔寫得再好，但代碼還是可能寫得一團糟。
執行效果的保障成了新的問題~
無處不在的規範
在這種情況下代碼檢驗工具應運而生，開發者可以把編碼規範寫成配置文件，再配合工具對代碼進行檢驗。
同時在開發環境中使用插件來實時提示開發者遵守校驗規則。
即使開發者提交了不符合規範的代碼，也可以在部署之前用多種方式阻止代碼部署，比如利用git的鉤子程序或者在持續集成中進行檢驗。
這種方式很具有工程思維，能合理利用工具解決問題，這樣的代碼已經基本具有“風格一致”的特點了。但校驗工具的作用也是有限的，無法理解代碼語義。
理想的代碼規範
既然這些都不完美，到底有沒有更好的解決方案？
沒有~也有~
確實沒有找到一勞永逸的工具或方法，但是值得慶幸的是我們可以把他們結合起來：使用靜態校驗工具來規範代碼的基本書寫規範，然後對於校驗工具無法完成的規範寫成文檔，最後通過代碼合併時的代碼審查進行保障。
例如我為現在前端項目的規範就包括多種形式：
- 對於腳本語言TypeScript和預處理語言Sass，直接省略了規範文檔，採用的是使用對應的校驗工具tslint和sasslint，編輯器集成的插件可以及時提醒開發者遵循規範，對於有疑問的錯誤信息也很容易在網上進行查找。
- 對於比較靈活的部分，如變量命名、文件創建以及代碼內容則採用文檔描述加上代碼評審的方式，評審方式為互評，先由其它開發者查閱代碼進行評論，然後再轉給管理員進行審核。
當然這種方式在初期的磨合成本是會略高一些，比如校驗規則沒有文檔說明，評審耗費時間等。但是隨著開發不斷進行，這種成本會不斷降低到趨近於0，因為代碼寫的越多對規範越熟悉，評審改進次數越多也能促進團隊在編碼上達成共識。
最後
懂得避免的問題勝過懂得解決問題，好的規範能避免寫出糟糕的代碼，為以後節省大量重構、修復bug的時間。
閱讀更多 慕課網 的文章
