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

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

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

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

1 工作流規(guī)范

1.1.1 版本規(guī)范

1.1.2 版本控制系統(tǒng)規(guī)范

1.1.3 提交信息規(guī)范

1.1 開發(fā)

1.2 構建規(guī)范

1.3 發(fā)布工作流規(guī)范

1.4 持續(xù)集成

1.5 任務管理

2 技術棧規(guī)范

2.1 技術選型

2.2 迎接新技術

3 瀏覽器兼容規(guī)范

3.1 確定兼容策略

3.2 確定瀏覽器分級

3.3 獲取統(tǒng)計數(shù)據(jù)

4 項目組織規(guī)范

4.1 通用的項目組織規(guī)范

4.2 目錄組織的風格

4.3 腳手架和項目模板

5 編碼規(guī)范

5.1 Javascript

5.2 HTML

5.3 CSS

5.4 代碼格式化

5.5 集大成的

5.6 特定框架風格指南

5.7 Code Review

6 文檔規(guī)范

6.1 建立文檔中心

6.2 文檔格式

6.3 定義文檔的模板

6.4 討論即文檔

6.5 注釋即文檔

6.6 代碼即文檔

7 UI設計規(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 培訓/知識管理/技術沉淀

11.1 新人培訓

11.2 營造技術氛圍

12 反饋

CHANGELOG

2019.7.28 新增技術選型

2019.7.29 新增瀏覽器統(tǒng)計數(shù)據(jù)獲取

2019.9.6 建立技術氛圍一節(jié) 新增面試題庫

什么是規(guī)范?

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

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

降低新成員融入團隊的成本, 同時也一定程度避免挖坑

提高開發(fā)效率、團隊協(xié)作效率, 降低溝通成本

實現(xiàn)高度統(tǒng)一的代碼風格，方便review, 另外一方面可以提高項目的可維護性

規(guī)范是實現(xiàn)自動化的基礎

規(guī)范是一個團隊知識沉淀的直接輸出

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

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

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

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

1 工作流規(guī)范

1.1 開發(fā)

項目的版本號應該根據(jù)某些規(guī)則進行迭代, 這里推薦使用語義化版本規(guī)范, 通過這個規(guī)范，用戶可以了解版本變更的影響范圍。 規(guī)則如下:

主版本號：當你做了不兼容的 API 修改，

次版本號：當你做了向下兼容的功能性新增，

修訂號：當你做了向下兼容的問題修正。

??回到頂部

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

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

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

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

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

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

簡單的集中式

基于功能分支的工作流

Git Flow

web前端 Git

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。