一、命名規則(英文-直譯)
1、檔案命名
資料夾/檔案的命名統一用小寫
保證專案有良好的可移植性,可跨平臺
相關參考
2、檔案引用路徑
因為檔案命名統一小寫,引用也需要注意大小寫問題
3、js變數
3.1 變數
命名方式:小駝峰
命名規範:字首名詞
命名建議:語義化
案例
1 2 3 4 5 6 7 8 9 10 11 12 |
// 友好 let maxCount = 10; let tableTitle = 'LoginTable'; // 不友好 let setCount = 10; let getTitle = 'LoginTable'; |
3.2 常量
命名方式:全部大寫
命名規範:使用大寫字母和下劃線來組合命名,下劃線用以分割單詞
命名建議:語義化
案例
1 2 3 4 |
const MAX_COUNT = 10; const URL = 'http://www.foreverz.com'; |
3.3 函式
命名方式:小駝峰式命名法。
命名規範:字首應當為動詞。
命名建議:語義化
可以參考如下的動作
動詞 | 含義 | 返回值 |
---|---|---|
can | 判斷是否可執行某個動作(許可權) | 函式返回一個布林值。true:可執行;false:不可執行 |
has | 判斷是否含有某個值 | 函式返回一個布林值。true:含有此值;false:不含有此值 |
is | 判斷是否為某個值 | 函式返回一個布林值。true:為某個值;false:不為某個值 |
get | 獲取某個值 | 函式返回一個非布林值 |
set | 設定某個值 | 無返回值、返回是否設定成功或者返回鏈式物件 |
load | 載入某些資料 | 無返回值或者返回是否載入完成的結果 |
1 2 3 4 5 6 7 8 |
// 是否可閱讀 function canRead(): boolean { return true; } // 獲取名稱 function getName(): string { return this.name; } |
3.4 類、建構函式
命名方式:大駝峰式命名法,首字母大寫
命名規範:字首為名稱。
命名建議:語義化
案例
1 2 3 4 5 6 7 8 |
class Person { public name: string; constructor(name) { this.name = name; } } const person = new Person('mevyn'); |
公共屬性和方法:
跟變數和函式的命名一樣。
私有屬性和方法:
字首為_(下劃線),後面跟公共屬性和方法一樣的命名方式。
案例
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
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
1 2 |
我們還是使用大團隊比較常用的BEM模式 |
(1)class
命名使用BEM其實是塊(block
)、元素(element
)、修飾符(modifier
)的縮寫,利用不同的區塊,功能以及樣式來給元素命名。這三個部分使用__與–連線(這裡用兩個而不是一個是為了留下用於塊兒的命名)。
命名約定的模式如下:
1 2 3 4 5 6 7 |
.block{} .block__element{} .block--modifier{} block 代表了更高階別的抽象或元件 block__element 代表 block 的後代,用於形成一個完整的 block 的整體 block--modifier代表 block 的不同狀態或不同版本 |
(2)id
一般參與樣式,命名的話使用駝峰,如果是給js呼叫鉤子就需要設定為js_xxxx
的方式
二、註釋
1.單行註釋
1 2 |
// 這個函式的執行條件,執行結果大概說明 dosomthing() |
2.多行註釋
1 2 3 4 5 |
/* * xxxx 描述較多的時候可以使用多行註釋 * xxxx */ dosomthing(); |
3.函式(方法)註釋 參考jsdoc
註釋名 | 語法 | 含義 | 示例 |
---|---|---|---|
@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部分和業務部分,基礎元件一般是承載呈現,基礎功能,不和業務耦合部分。
業務元件一般包含業務功能業務特殊資料等等
1 UI元件/基礎元件
開發的時候注意可擴充性,支援資料傳參進行渲染,支援插槽slot
設定有mixin,mixin中放了基礎資訊和方法
2 容器元件
和當前業務耦合性比較高,由多個基礎元件組成,可承載當前頁的業務介面請求和資料(vuex)
3 元件存放位置
(1)ui元件存放在src/components/
中
包含xxx.vue
和 xxmixin.js
和 readme.md
1 2 3 |
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控制元件的掛在和銷燬
1 |
<testcomponent v-if='componentActive'> </testcomponent> |
(2)通過is控制元件的掛在和銷燬
1 |
<component is='componentName'> </component> |
6 跨專案元件共用
公共元件存放位置中 定時抽取共用次數多的元件 將他放在npm.kuaizi.co中,供下載引用
四、codeReview
1 規則
所有影響到以往流程的功能需求更改發版前都需要codeReview
2 執行者
初級程式設計師可由中級程式設計師的執行codeReview
中級程式設計師可由高階程式設計師執行codeReview
以此類推
3 反饋
每次codereView都需要有反饋,要對本次codeReview負責
反饋內容基本如
1 2 3 4 |
功能:本次主要是修改了什麼功能或者bug 模組:本次發版影響的模組 程式碼問題:codereview過程中發現的程式碼問題,比如程式碼效能,寫法,程式碼風格等等 業務問題:比如發現了某某影響到其他模組的邏輯問題,如果沒有發現就寫。無 |
五、git規範
1 分支
命名
1 2 3 4 5 6 7 8 9 10 11 |
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
在完善中,會繼承自動檢測程式碼,可選輸入發版提交版本基本資訊等等
六、分享會
每兩週至少執行一次,分享工作,生活各方面都可以