前端小團隊建設

發表於2018-09-22

一、命名規則(英文-直譯)

1、檔案命名

資料夾/檔案的命名統一用小寫
保證專案有良好的可移植性,可跨平臺
相關參考

2、檔案引用路徑

因為檔案命名統一小寫,引用也需要注意大小寫問題

3、js變數

3.1 變數

命名方式:小駝峰

命名規範:字首名詞

命名建議:語義化

案例

3.2 常量

命名方式:全部大寫

命名規範:使用大寫字母和下劃線來組合命名,下劃線用以分割單詞

命名建議:語義化

案例

3.3 函式

命名方式:小駝峰式命名法。

命名規範:字首應當為動詞。

命名建議:語義化

可以參考如下的動作
動詞 含義 返回值
can 判斷是否可執行某個動作(許可權) 函式返回一個布林值。true:可執行;false:不可執行
has 判斷是否含有某個值 函式返回一個布林值。true:含有此值;false:不含有此值
is 判斷是否為某個值 函式返回一個布林值。true:為某個值;false:不為某個值
get 獲取某個值 函式返回一個非布林值
set 設定某個值 無返回值、返回是否設定成功或者返回鏈式物件
load 載入某些資料 無返回值或者返回是否載入完成的結果

3.4 類、建構函式

命名方式:大駝峰式命名法,首字母大寫

命名規範:字首為名稱。

命名建議:語義化

案例

公共屬性和方法:跟變數和函式的命名一樣。

私有屬性和方法:字首為_(下劃線),後面跟公共屬性和方法一樣的命名方式。

案例

3.5 css(class、id)命名規則BEM

(1)class命名使用BEM其實是塊(block)、元素(element)、修飾符(modifier)的縮寫,利用不同的區塊,功能以及樣式來給元素命名。這三個部分使用__與–連線(這裡用兩個而不是一個是為了留下用於塊兒的命名)。
命名約定的模式如下:

(2)id一般參與樣式,命名的話使用駝峰,如果是給js呼叫鉤子就需要設定為js_xxxx的方式

二、註釋

1.單行註釋

2.多行註釋

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.vuexxmixin.jsreadme.md

名詞 含義 案例
@name 元件名稱 篩選下拉框
@version 版本 v1.0.0
@updateTime 更新日期 2018.09.18
@describe 使用場景描述 某某場景下
@props 引數 [‘data’]
@author 作者 dd

如下圖
引用元件的時候 直接引入 mixinElementFilter.js 即可。在引用元件的頁面可以對mixin裡面的方法進行重構
clipboard.png

(2)業務元件就放在業務模組部分即可

4 元件通訊

避免資料的分發源混亂,不建議使用eventBus控制資料,應使用props來和$emit來資料分發和傳送

同級元件的通訊一般會有一箇中間容器元件作為橋樑

容器元件作為資料的接受和分發點

5 元件的掛在和銷燬

(1)通過v-if控制元件的掛在和銷燬

(2)通過is控制元件的掛在和銷燬

6 跨專案元件共用

公共元件存放位置中 定時抽取共用次數多的元件 將他放在npm.kuaizi.co中,供下載引用

四、codeReview

1 規則

所有影響到以往流程的功能需求更改發版前都需要codeReview

2 執行者

初級程式設計師可由中級程式設計師的執行codeReview
中級程式設計師可由高階程式設計師執行codeReview
以此類推

3 反饋

每次codereView都需要有反饋,要對本次codeReview負責

反饋內容基本如

五、git規範

1 分支

命名

斜槓 的方式 在source-tree中有歸類的作用

2 提交模版 kz-commit

在完善中,會繼承自動檢測程式碼,可選輸入發版提交版本基本資訊等等

六、分享會

每兩週至少執行一次,分享工作,生活各方面都可以

參考:

https://juejin.im/entry/599d4…

相關文章