if 我是前端團(tuán)隊(duì) Leader，怎么制定前端協(xié)作規(guī)范?

萬字長文，繼續(xù)刷新我的文章長度記錄，涉及前端開發(fā)的方方面面。本文將持續(xù)更新和完善, 文章部分觀點(diǎn)可能比較武斷或不完整，歡迎評(píng)論和補(bǔ)充，一起完善該文章. 謝謝

筆者長期單槍匹馬在前端領(lǐng)域廝殺(言外之意就是團(tuán)隊(duì)就一個(gè)人)，自己就是規(guī)范。隨著公司業(yè)務(wù)的擴(kuò)展，擴(kuò)充了一些人員，這時(shí)候就要開始考慮協(xié)作和編碼規(guī)范問題了。本文記錄了筆者在制定前端協(xié)作規(guī)范時(shí)的一些思考，希望能給你們也帶來一些幫助.

一個(gè)人走的更快，一群人可以走得更遠(yuǎn)，前提是統(tǒng)一的策略，還要不斷地反省和優(yōu)化。

以下是目錄概覽, 看出這是一篇浩浩蕩蕩的長文

1 工作流規(guī)范
1.1 開發(fā)
1.1.1 版本規(guī)范
1.1.2 版本控制系統(tǒng)規(guī)范
1.1.3 提交信息規(guī)范
1.2 構(gòu)建規(guī)范
1.3 發(fā)布工作流規(guī)范
1.4 持續(xù)集成
1.5 任務(wù)管理
2 技術(shù)棧規(guī)范
2.1 技術(shù)選型
2.2 迎接新技術(shù)
3 瀏覽器兼容規(guī)范
3.1 確定兼容策略
3.2 確定瀏覽器分級(jí)
3.3 獲取統(tǒng)計(jì)數(shù)據(jù)
4 項(xiàng)目組織規(guī)范
4.1 通用的項(xiàng)目組織規(guī)范
4.2 目錄組織的風(fēng)格
4.3 腳手架和項(xiàng)目模板
5 編碼規(guī)范
5.1 Javascript
5.2 HTML
5.3 CSS
5.4 代碼格式化
5.5 集大成的
5.6 特定框架風(fēng)格指南
5.7 Code Review
6 文檔規(guī)范
6.1 建立文檔中心
6.2 文檔格式
6.3 定義文檔的模板
6.4 討論即文檔
6.5 注釋即文檔
6.6 代碼即文檔
7 UI設(shè)計(jì)規(guī)范
8 測試規(guī)范
8.1 測試的流程
8.2 單元測試
9 異常處理、監(jiān)控和調(diào)試規(guī)范
9.1 異常處理
9.2 日志
9.3 異常監(jiān)控
10 前后端協(xié)作規(guī)范
10.1 協(xié)作流程規(guī)范
10.2 接口規(guī)范
10.3 接口文檔規(guī)范
10.4 接口測試與模擬
11 培訓(xùn)/知識(shí)管理/技術(shù)沉淀
11.1 新人培訓(xùn)
11.2 營造技術(shù)氛圍
12 反饋

CHANGELOG

2019.7.28 新增技術(shù)選型
2019.7.29 新增瀏覽器統(tǒng)計(jì)數(shù)據(jù)獲取
2019.9.6 建立技術(shù)氛圍一節(jié) 新增面試題庫

什么是規(guī)范?

規(guī)范，名詞意義上：即明文規(guī)定或約定俗成的標(biāo)準(zhǔn)，如：道德規(guī)范、技術(shù)規(guī)范等。 動(dòng)詞意義上：是指按照既定標(biāo)準(zhǔn)、規(guī)范的要求進(jìn)行操作，使某一行為或活動(dòng)達(dá)到或超越規(guī)定的標(biāo)準(zhǔn)，如：規(guī)范管理、規(guī)范操作.

為什么需要規(guī)范?

降低新成員融入團(tuán)隊(duì)的成本, 同時(shí)也一定程度避免挖坑
提高開發(fā)效率、團(tuán)隊(duì)協(xié)作效率, 降低溝通成本
實(shí)現(xiàn)高度統(tǒng)一的代碼風(fēng)格，方便review, 另外一方面可以提高項(xiàng)目的可維護(hù)性
規(guī)范是實(shí)現(xiàn)自動(dòng)化的基礎(chǔ)
規(guī)范是一個(gè)團(tuán)隊(duì)知識(shí)沉淀的直接輸出

規(guī)范包含哪些內(nèi)容?

如文章標(biāo)題，前端協(xié)作規(guī)范并不單單指‘編碼規(guī)范’，這個(gè)規(guī)范涉及到前端開發(fā)活動(dòng)的方方面面，例如代碼庫的管理、前后端協(xié)作、代碼規(guī)范、兼容性規(guī)范；

不僅僅是前端團(tuán)隊(duì)內(nèi)部需要協(xié)作，一個(gè)完整的軟件生命周期內(nèi)，我們需要和產(chǎn)品/設(shè)計(jì)、后端(或者原生客戶端團(tuán)隊(duì))、測試進(jìn)行協(xié)作, 我們需要覆蓋這些內(nèi)容.

下面就開始介紹，如果我是前端團(tuán)隊(duì)的Leader，我會(huì)怎么制定前端規(guī)范，這個(gè)規(guī)范需要包含哪些內(nèi)容?

1 工作流規(guī)范
1.1 開發(fā)
1.1.1 版本規(guī)范
項(xiàng)目的版本號(hào)應(yīng)該根據(jù)某些規(guī)則進(jìn)行迭代, 這里推薦使用語義化版本規(guī)范, 通過這個(gè)規(guī)范，用戶可以了解版本變更的影響范圍。 規(guī)則如下:

主版本號(hào)：當(dāng)你做了不兼容的 API 修改，
次版本號(hào)：當(dāng)你做了向下兼容的功能性新增，
修訂號(hào)：當(dāng)你做了向下兼容的問題修正。

??回到頂部

1.1.2 版本控制系統(tǒng)規(guī)范
大部分團(tuán)隊(duì)都使用git作為版本庫，管理好代碼也是一種學(xué)問。尤其是涉及多人并發(fā)協(xié)作、需要管理多個(gè)軟件版本的情況下，定義良好的版本庫管理規(guī)范，可以讓大型項(xiàng)目更有組織性，也可以提高成員協(xié)作效率.

比較流行的git分支模型/工作流是git-flow, 但是大部分團(tuán)隊(duì)會(huì)根據(jù)自己的情況制定自己的git工作流規(guī)范, 例如我們團(tuán)隊(duì)的分支規(guī)范

Git 有很多工作流方法論，這些工作流的選擇可能依賴于項(xiàng)目的規(guī)模、項(xiàng)目的類型以及團(tuán)隊(duì)成員的結(jié)構(gòu).

比如一個(gè)簡單的個(gè)人項(xiàng)目可能不需要復(fù)雜的分支劃分，我們的變更都是直接提交到 master 分支;

再比如開源項(xiàng)目，除了核心團(tuán)隊(duì)成員，其他貢獻(xiàn)者是沒有提交的權(quán)限的，而且我們也需要一定的手段來驗(yàn)證和討論貢獻(xiàn)的代碼是否合理。 所以對(duì)于開源項(xiàng)目 fork 工作流更為適合.

了解常見的工作流有利于組織或創(chuàng)建適合自己團(tuán)隊(duì)的工作流, 提交團(tuán)隊(duì)協(xié)作的效率:

簡單的集中式
基于功能分支的工作流
Git Flow