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