>來自[spademan](https://segmentfault.com/a/1190000016445088)
## 一、命名規則（英文-直譯）
>[info]1、文件命名
文件夾/文件的命名統一用小寫。
保證項目有良好的可移植性，可跨平臺。相關參考：[《為什么文件名要小寫？》](https://mp.weixin.qq.com/s?__biz=MzAwNDcyNjI3OA==&mid=2650839826&idx=2&sn=32374331c2c4af306cc838b33b87dc64&chksm=80d3b07bb7a4396d8ec40f9f205b8372048c6d7c800154ff4f5714afac58a81b42affaff83d8&scene=21#wechat_redirect)。
>[info]2、文件引用路徑
因為文件命名統一小寫，引用也需要注意大小寫問題。
>[info]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` 的方式。
## 二、注釋
>[info]1、單行注釋
~~~
// 這個函數的執行條件，執行結果大概說明
dosomthing()
~~~
>{info}2、多行注釋
~~~
/*
* xxxx 描述較多的時候可以使用多行注釋
* xxxx
*/
dosomthing();
~~~
## 3、函數（方法）注釋
| 注釋名 | 語法 | 含義 | 示例 |
|---|---|---|---|
| @param | @param 參數名 {參數類型} 描述信息 | 描述參數的信息 | @param name {String} 傳入名稱 |
| @return @return {返回類型} 描述信息 | 描述返回值的信息 | @return {Boolean} | true:可執行;false:不可執行 |
| @author | @author 作者信息 [附屬信息：如郵箱、日期] | 描述此函數作者的信息 | @author 張三 2015/07/21 |
| @version | @version XX.XX.XX | 描述此函數的版本號 | @version 1.0.3 |
| @example | @example 示例代碼 | 演示函數的使用 | @example setTitle(‘測試’) |
## 三、組件
每個 Vue 組件的代碼建議不要超出 200 行，如果超出建議拆分組件。
組件一般情況下是可以拆成基礎/ui部分和業務部分，基礎組件一般是承載呈現，基礎功能，不和業務耦合部分。
業務組件一般包含業務功能業務特殊數據等等。
>[info]1、UI組件/基礎組件
開發的時候注意可拓展性，支持數據傳參進行渲染，支持插槽slot。
設置有mixin，mixin中放了基礎信息和方法。
>[info]2、容器組件
和當前業務耦合性比較高，由多個基礎組件組成，可承載當前頁的業務接口請求和數據(vuex)。
>[info]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）業務組件就放在業務模塊部分即可。
>[info] 4、組件通訊
避免數據的分發源混亂，不建議使用 eventBus控制數據，應使用 props來和 $emit來數據分發和傳送。
同級組件的通訊一般會有一個中間容器組件作為橋梁。
容器組件作為數據的接受和分發點。
>[info]5、組件的掛在和銷毀
（1）通過`v-if`控制組件的掛在和銷毀
`<testcomponent v-if='componentActive'> </testcomponent>`
（2）通過is控制組件的掛在和銷毀
`<component is='componentName'> </component>`
>[info]6、跨項目組件共用
公共組件存放位置中 定時抽取共用次數多的組件 將他放在` npm.kuaizi.co`中，供下載引用。
## 四、codeReview
>[info]1、規則
所有影響到以往流程的功能需求更改發版前都需要 `codeReview`。
>[info]2、執行者
初級程序員可由中級程序員的執行 `codeReview`。
中級程序員可由高級程序員執行 `codeReview`。
以此類推。
>[info]3、反饋
每次`codereView`都需要有反饋，要對本次`codeReview`負責。
反饋內容基本如：
>[success]功能：本次主要是修改了什么功能或者bug。模塊：本次發版影響的模塊。
代碼問題：codereview過程中發現的代碼問題，比如代碼性能，寫法，代碼風格等等。業務問題：比如發現了某某影響到其他模塊的邏輯問題，如果沒有發現就寫無。
## 五、git規范
>[info]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`中有歸類的作用。
>[info]2、提交模版 kz-commit
在完善中，會繼承自動檢測代碼，可選輸入發版提交版本基本信息等等。
## 六、分享會
每兩周至少執行一次，分享工作，生活各方面都可以。
