本篇文章講怎么在前端團隊快速制定并落地代碼規(guī)范!!!
干貨，拿走這個倉庫^[1]

一、背景

9月份換了一個新部門，部門成立時間不長，當時組內(nèi)還沒有統(tǒng)一的代碼規(guī)范（部分工程用了規(guī)范，部分沒有，沒有統(tǒng)一的收口）

小組的技術棧框架有Vue，React，Taro，Nuxt，用Typescript，算是比較雜了，結合到部門后續(xù)還可能擴展其他技術棧，我們從0-1實現(xiàn)了一套通用的代碼規(guī)范

到現(xiàn)在小組內(nèi)也用起來幾個月了，整個過程還算是比較順利且快速，最近得空分享出來～

??本篇文章不會講基礎的具體的規(guī)范，而是從實踐經(jīng)驗講怎么制定規(guī)范以及落地規(guī)范

二、為什么要代碼規(guī)范

就不說了...大家懂的~

不是很了解的話，指路^[2]

三、確定規(guī)范范圍

首先，跟主管同步，團隊需要一個統(tǒng)一的規(guī)范，相信主管也在等著人來做起來

第一步收集團隊的技術棧情況，確定規(guī)范要包括的范圍

把規(guī)范梳理為三部分ESLint、StyleLint、CommitLint，結合團隊實際情況分析如下

• ESLint：團隊統(tǒng)一用的TypeScript，框架用到了Vue、React、Taro、還有Nuxt
• StyleLint：團隊統(tǒng)一用的Less
• CommitLint：git代碼提交規(guī)范

當然，還需考慮團隊后續(xù)可能會擴展到的技術棧，以保證實現(xiàn)的時候確保可擴展性

四、調(diào)研業(yè)內(nèi)實現(xiàn)方案

常見以下3種方案

1. 團隊制定文檔式代碼規(guī)范，成員都人為遵守這份規(guī)范來編寫代碼

   靠人來保證代碼規(guī)范存在不可靠，且需要人為review代碼不規(guī)范，效率低

2. 直接使用業(yè)內(nèi)已有成熟規(guī)范，比如css使用StyleLint官方推薦規(guī)范stylelint-config-standard、stylelint-order，JavaScript使用ESLint推薦規(guī)范eslint:recommended等

   a)?開源規(guī)范往往不能滿足團隊需求，可拓展性差; b)?業(yè)內(nèi)提供的規(guī)范都是獨立的（stylelint只提供css代碼規(guī)范，ESLint只提供JavaScript規(guī)范），是零散的，對于規(guī)范初始化或升級存在成本高、不可靠問題（每個工程需要做人為操作多個步驟）

3. 基于StyleLint、ESLint制定團隊規(guī)范npm包，使用團隊制定規(guī)范庫

   a)?該方案解決可擴展性差的問題，但是第二點中的（b）問題依舊存在

五、我們的技術方案

整體技術思路圖如下圖，提供三個基礎包@jd/stylelint-config-selling、@jd/eslint-config-selling、@jd/commitlint-config-selling分別滿足StyleLint、ESLint、CommitLint

1. @jd/stylelint-config-selling包括css、less、sass(團隊暫未使用到)
2. @jd/eslint-config-selling包括Vue、React、Taro、Next、nuxt(團隊暫未使用到)...，還包括后續(xù)可能會擴展到需要自定義的ESLint插件或者解析器
3. @jd/commitlint-config-selling統(tǒng)一使用git

向上提供一個簡單的命令行工具，交互式初始化init、或者更新update規(guī)范

幾個關鍵點

1、用lerna統(tǒng)一管理包

lerna^[3]是一個管理工具，用于管理包含多個軟件包（package）的 JavaScript項目，業(yè)內(nèi)已經(jīng)廣泛使用了，不了解的可以自己找資料看下
項目結構如下圖

2、三個基礎包的依賴包都設置為生產(chǎn)依賴dependencies

如下圖，包@jd/eslint-config-selling的依賴包都寫在了生產(chǎn)依賴，而不是開發(fā)依賴
解釋下：開發(fā)依賴&生產(chǎn)依賴

• 開發(fā)依賴：業(yè)務工程用的時候不會下載開發(fā)依賴中的包，業(yè)內(nèi)常見的規(guī)范如standard、airbnb都是寫在開發(fā)依賴
• 缺點：業(yè)務工程除了安裝@jd/eslint-config-selling外，需要自己去安裝前置依賴包，如eslint、根據(jù)自己選擇的框架安裝相關前置依賴包如使用的Vue需要安裝eslint-plugin-vue...使用成本、維護升級成本較高
• 優(yōu)點：按需安裝包，開發(fā)時不會安裝多余的包（Lint相關的包在業(yè)務工程中都是開發(fā)依賴，所以只會影響開發(fā)時）
• 生產(chǎn)依賴：業(yè)務工程用的時候會下載這些包
• 優(yōu)點：安裝@jd/eslint-config-selling后，無需關注前置依賴包
• 缺點：開發(fā)時會下載@jd/eslint-config-selling中所有寫在生產(chǎn)依賴的包，即使有些用不到，比如你使用的是React，卻安裝了eslint-plugin-vue

3、提供簡單的命令行

這個比較簡單，提供交互式命令，支持一鍵初始化或者升級3種規(guī)范，就不展開說了

不會的，指路中高級前端必備：如何設計并實現(xiàn)一個腳手架^[4]

組里現(xiàn)在還沒有項目模版腳手架，后續(xù)有的話需要把規(guī)范這部分融進去

六、最重要的一點

什么是一個好的規(guī)范？
基本每個團隊的規(guī)范都是不一樣的，團隊各成員都認同并愿意遵守的規(guī)范

所以確定好技術方案后，涉及到的各個規(guī)范，下圖，我們在小組內(nèi)分工去制定，比如幾個人去制定styleLint的，幾個人制定Vue的...

然后拉會評審，大家統(tǒng)一通過的規(guī)范才敲定 最后以開源的方式維護升級，使用過程中，遇到規(guī)范不合適的問題，提交issue，大家統(tǒng)一討論確定是否需要更改規(guī)范

寫在結尾

以上就是我們團隊在前端規(guī)范落地方面的經(jīng)驗～

如果大家感興趣，可查看github倉庫^{[5]??https://github.com/jd-antelope/s-lint}