if 我是前端團隊 Leader，怎么制定前端協作規范?

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

筆者長期單槍匹馬在前端領域廝殺(言外之意就是團隊就一個人)，自己就是規范。隨著公司業務的擴展，擴充了一些人員，這時候就要開始考慮協作和編碼規范問題了。本文記錄了筆者在制定前端協作規范時的一些思考，希望能給你們也帶來一些幫助.

一個人走的更快，一群人可以走得更遠，前提是統一的策略，還要不斷地反省和優化。

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

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

CHANGELOG

2019.7.28 新增技術選型
2019.7.29 新增瀏覽器統計數據獲取
2019.9.6 建立技術氛圍一節 新增面試題庫

什么是規范?

規范，名詞意義上：即明文規定或約定俗成的標準，如：道德規范、技術規范等。 動詞意義上：是指按照既定標準、規范的要求進行操作，使某一行為或活動達到或超越規定的標準，如：規范管理、規范操作.

為什么需要規范?

降低新成員融入團隊的成本, 同時也一定程度避免挖坑
提高開發效率、團隊協作效率, 降低溝通成本
實現高度統一的代碼風格，方便review, 另外一方面可以提高項目的可維護性
規范是實現自動化的基礎
規范是一個團隊知識沉淀的直接輸出

規范包含哪些內容?

如文章標題，前端協作規范并不單單指‘編碼規范’，這個規范涉及到前端開發活動的方方面面，例如代碼庫的管理、前后端協作、代碼規范、兼容性規范；

不僅僅是前端團隊內部需要協作，一個完整的軟件生命周期內，我們需要和產品/設計、后端(或者原生客戶端團隊)、測試進行協作, 我們需要覆蓋這些內容.

下面就開始介紹，如果我是前端團隊的Leader，我會怎么制定前端規范，這個規范需要包含哪些內容?

1 工作流規范
1.1 開發
1.1.1 版本規范
項目的版本號應該根據某些規則進行迭代, 這里推薦使用語義化版本規范, 通過這個規范，用戶可以了解版本變更的影響范圍。 規則如下:

主版本號：當你做了不兼容的 API 修改，
次版本號：當你做了向下兼容的功能性新增，
修訂號：當你做了向下兼容的問題修正。

??回到頂部

1.1.2 版本控制系統規范
大部分團隊都使用git作為版本庫，管理好代碼也是一種學問。尤其是涉及多人并發協作、需要管理多個軟件版本的情況下，定義良好的版本庫管理規范，可以讓大型項目更有組織性，也可以提高成員協作效率.

比較流行的git分支模型/工作流是git-flow, 但是大部分團隊會根據自己的情況制定自己的git工作流規范, 例如我們團隊的分支規范

Git 有很多工作流方法論，這些工作流的選擇可能依賴于項目的規模、項目的類型以及團隊成員的結構.

比如一個簡單的個人項目可能不需要復雜的分支劃分，我們的變更都是直接提交到 master 分支;

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

了解常見的工作流有利于組織或創建適合自己團隊的工作流, 提交團隊協作的效率:

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