前端小團隊建設
一、命名規則（英文-直譯）
1、檔案命名
資料夾/檔案的命名統一用小寫。
保證專案有良好的可移植性，可跨平臺。相關參考：《為什麼檔名要小寫？》。
2、檔案引用路徑
因為檔案命名統一小寫，引用也需要注意大小寫問題。
3、js變數
3.1 變數
命名方式：小駝峰
命名規範：字首名詞
命名建議：語義化
案例：
// 友好
let maxCount = 10;
let tableTitle = 'LoginTable';
// 不友好
let setCount = 10;
let getTitle = 'LoginTable';
3.2 常量
命名方式：全部大寫
命名規範：使用大寫字母和下劃線來組合命名，下劃線用以分割單詞
命名建議：語義化
案例：
const MAX_COUNT = 10;
const URL = 'http://www.foreverz.com';
3.3 函式
命名方式：小駝峰式命名法。
命名規範：字首應當為動詞。
命名建議：語義化
可以參考如下的動作：
動詞含義返回值
can判斷是否可執行某個動作(許可權)函式返回一個布林值。true：可執行；false：不可執行
has判斷是否含有某個值函式返回一個布林值。true：含有此值；false：不含有此值
is判斷是否為某個值函式返回一個布林值。true：為某個值；false：不為某個值
get獲取某個值函式返回一個非布林值
set設定某個值無返回值、返回是否設定成功或者返回鏈式物件
load載入某些資料無返回值或者返回是否載入完成的結果
案例：
// 是否可閱讀
function canRead(): boolean {
return true;
}
// 獲取名稱
function getName(): string {
return this.name;
}
3.4 類、建構函式
命名方式：大駝峰式命名法，首字母大寫
命名規範：字首為名稱。
命名建議：語義化
案例：
class Person {
public name: string;
constructor(name) {
this.name = name;
}
}
const person = new Person('mevyn');
公共屬性和方法：跟變數和函式的命名一樣。
私有屬性和方法：字首為_（下劃線），後面跟公共屬性和方法一樣的命名方式。
案例：
class Person {
private _name: string;
constructor() { }
// 公共方法
getName() {
return this._name;
}
// 公共方法
setName(name) {
this._name = name;
}
}
const person = new Person();
person.setName('mervyn');
person.getName(); // ->mervyn
3.5 css（class、id）命名規則BEM
我們還是使用大團隊比較常用的BEM模式。
（1）class命名使用BEM其實是塊（block）、元素（element）、修飾符（modifier）的縮寫，利用不同的區塊，功能以及樣式來給元素命名。這三個部分使用__與--連線（這裡用兩個而不是一個是為了留下用於塊兒的命名）。
命名約定的模式如下：
.block{}
.block__element{}
.block--modifier{}
block 代表了更高級別的抽象或元件。
block__element 代表 block 的後代，用於形成一個完整的 block 的整體
block--modifier代表 block 的不同狀態或不同版本
（2）id一般參與樣式，命名的話使用駝峰，如果是給js呼叫鉤子就需要設定為js_xxxx的方式。
二、註釋
1、單行註釋
// 這個函式的執行條件，執行結果大概說明
dosomthing()
2、多行註釋
/*
* xxxx 描述較多的時候可以使用多行註釋
* xxxx
*/
dosomthing();
3、函式（方法）註釋
註釋名語法含義示例
@[email protected] 引數名 {引數型別} 描述資訊描述引數的資訊@param name {String} 傳入名稱
@return @return {返回型別} 描述資訊描述返回值的資訊@return {Boolean}true:可執行;false:不可執行
@[email protected] 作者資訊 [附屬資訊：如郵箱、日期]描述此函式作者的資訊@author 張三 2015/07/21
@[email protected] XX.XX.XX描述此函式的版本號@version 1.0.3
@[email protected] 示例程式碼演示函式的使用@example setTitle(‘測試’)
三、元件
每個 Vue 元件的程式碼建議不要超出 200 行，如果超出建議拆分元件。
元件一般情況下是可以拆成基礎/ui部分和業務部分，基礎元件一般是承載呈現，基礎功能，不和業務耦合部分。
業務元件一般包含業務功能業務特殊資料等等。
1、UI元件/基礎元件
開發的時候注意可拓展性，支援資料傳參進行渲染，支援插槽slot。
設定有mixin，mixin中放了基礎資訊和方法。
2、容器元件
和當前業務耦合性比較高，由多個基礎元件組成，可承載當前頁的業務介面請求和資料(vuex)。
3、元件存放位置
（1）ui元件存放在src/components/中，包含xxx.vue和xxmixin.js和readme.md。
xxx.vue 表示ui部分
xxmixin.js 表示js部分
readme.md 中描述元件的基本資訊
名詞含義案例
@name元件名稱篩選下拉框
@version版本v1.0.0
@updateTime更新日期2018.09.18
@describe使用場景描述某某場景下
@props引數['data']
@author作者dd
如下圖，引用元件的時候 直接引入mixinElementFilter.js即可。在引用元件的頁面可以對mixin裡面的方法進行重構：
（2）業務元件就放在業務模組部分即可。
4、元件通訊
避免資料的分發源混亂，不建議使用eventBus控制資料，應使用props來和$emit來資料分發和傳送。
同級元件的通訊一般會有一箇中間容器元件作為橋樑。
容器元件作為資料的接受和分發點。
5、元件的掛在和銷燬
（1）通過v-if控制組件的掛在和銷燬
<testcomponent v-if='componentActive'> </testcomponent>
（2）通過is控制組件的掛在和銷燬
<component is='componentName'> </component>
6、跨專案元件共用
公共元件存放位置中 定時抽取共用次數多的元件 將他放在npm.kuaizi.co中，供下載引用。
四、codeReview
1、規則
所有影響到以往流程的功能需求更改發版前都需要 codeReview。
2、執行者
初級程式設計師可由中級程式設計師的執行 codeReview。
中級程式設計師可由高階程式設計師執行 codeReview。
以此類推。
3、反饋
每次codereView都需要有反饋，要對本次codeReview負責。
反饋內容基本如：
功能：本次主要是修改了什麼功能或者bug。模組：本次發版影響的模組。程式碼問題：codereview過程中發現的程式碼問題，比如程式碼效能，寫法，程式碼風格等等。業務問題：比如發現了某某影響到其他模組的邏輯問題，如果沒有發現就寫無。
五、git規範
1、分支
命名：
master: master 分支就叫master 分支，線上環境正在使用的，每一次更新master都需要打tag。
test: test分支就供測試環境使用的分支。
develop: develop 分支就叫develop 分支。
feature: feature 分支 咱們暫時可以按 feature/name/version 這種命名規範來，後面有更好的命名規範咱們再改。version 表示當前迭代的版本號，name 表示當前迭代的名稱。
hotfix: hotfix 分支的命名我們暫時可以按 hotfix/name/version 這種來進行命名,verison表示這次修復的版本的版本號，name表示本次熱修復的內容標題。
斜槓的方式在source-tree中有歸類的作用。
2、提交模版 kz-commit
在完善中，會繼承自動檢測程式碼，可選輸入發版提交版本基本資訊等等。
六、分享會
每兩週至少執行一次，分享工作，生活各方面都可以。
擴充套件閱讀
來源：https://segmentfault.com/a/1190000016445088
微信公眾號：javafirst
掃碼關注免費獲取更多資源
