前端編碼規範

命名規範

• 變量名, 函數名 小駝峯【命名法 camel Case】: numberOfPeople 第一個單詞的首字母小寫；第二個單詞開始每一個單詞的的首字母大寫
• 組件名 大駝峯【命名法 Camel Case】: NumberOfPeople 每個單詞的首字母都大寫
• css樣式名 中橫線【命名法 kabab case】: number-of-people 單詞小寫用（-）中橫線分隔
• 常量名, graphql query 與 mutation變量名： 蛇底式大寫【命名法 upper snake case】: NUMBER_OF_PEOPLE 複合詞或短語中的各個單詞之間：下劃線（_）分隔而且沒有空格
• 禁用小寫加下劃線 ：number_of_people

命名方式	應用範圍	備註
camel Case	變量名, 函數名
Camel Case	組件名, 枚舉名	枚舉: SaveType = { BUILD: 'BUILD' }
kabab case	css樣式名
upper snake case	常量名, graphql query與 mutation變量名
snake case	禁止使用

應用範圍

<div class="bi-table">

<colgroup> <col width="auto" /> <col width="auto" /> <col width="auto" /> </colgroup>

<div data-type="p">結構</div>	<div data-type="p">應用範圍</div>	<div data-type="p">備註</div>
<div data-type="p">動+賓 (+ 副詞)</div>	<div data-type="p">函數名, graphql mutation名稱</div>	<div data-type="p"></div>
<div data-type="p">名詞(定語+名詞)</div>	<div data-type="p">組件名, 類名</div>	<div data-type="p"></div>
<div data-type="p">形容詞 (名詞+形容詞)</div> <div data-type="p">動詞被動形態</div> <div data-type="p">(be+xxx)</div>	<div data-type="p">狀態變量</div>	<div data-type="p">控制對話框是否顯示: dialogVisible</div> <div data-type="p"></div> <div data-type="p">儘量不要用 is+形容詞結構, 如 isSelected, 用 selected 就能夠了.</div> <div data-type="p"></div> <div data-type="p">is+名詞結構可使用, 如 isEnterprise</div>

</div>

名詞

__camel Case__: numberOfPeople
__Camel Case__: NumberOfPeople
__kabab case__: number-of-people
__snake case__: number_of_people
__upper snake case__: NUMBER_OF_PEOPLE

Merge Request Checklist

• 檢查是否和目標分支有衝突
• 檢查是否修復全部 dn test 的問題
• 檢查目錄、文件名拼寫
• 檢查 graphql 文件名拼寫，Query 首字母大寫的 CamelCase，Mutation 首字母小寫的 camelCase
• 檢查 conf 中的命名是否符合規範

標準的項目研發流程包括如下幾個階段：

* 評審階段
    * 需求評審
    * 交互評審
    * 視覺評審
* 開發階段
    * 原型開發
    * 用戶交互事件響應
    * 接入Mock數據
    * 後臺接口數據對接
* 聯調階段
    * 預發聯調
    * 整個業務串聯測試流程
* 測試階段
    * 埋點開發及驗證
    * 自測用例覆蓋
    * 交付提測
    * bug修復
* 發佈上線

寫做的基本準則（優化）

基本上寫做的基本準則的每一部分都能應用在代碼上：
    ● 讓段落成爲文章的基本結構：每一段對應一個主題。
    ● 去掉無用的單詞。 .
    ● 使用主動語態。
    ● 避免一連串鬆散的句子。
    ● 將相關的詞語放在一塊兒。
    ● 陳述句用主動語態。
    ● 平行的概念用平行的結構。
  這些對應的 用在前端的代碼風格上
    1. 讓函數成爲代碼的基本單元。每一個函數作一件事。
    2. 去掉無用的代碼
    3. 使用主動語態
    4. 避免一連串鬆散結構的代碼邏輯
    5. 把相關的變量、函數放在一塊兒。
    6. 表達式和陳述語句中使用主動語態。
    7. 用並行的代碼表達並行的概念。

Git分支

存在三種短時間分支

功能分支（feature branch）
        補丁分支（hotfix branch）
        預發分支（release branch）

Git Commit type

bug fix - 組件 bug 修復；
breaking change - 不兼容的改動；
new feature - 新功能

提交 Commit 類型前綴 主要以下：
feat: 新特性功能
fix: 缺陷修復bug
docs: 文檔相關
style: 樣式修改、錯別字修改、代碼的格式化改動，代碼邏輯並未產生任何變化
refactor: 重構或其餘方面的優化
perf: 性能提高
test: 增長測試
chore: 業務無關修改，如：發版、構建工具鏈修改等
scope 可選，做用域標識，指明你需改的代碼所屬做用域
subject 真實 Commit 描述，能說明白便可，字數不用太多

Git平常操做

git diff 查看修改內容

git bisect  二分查找法 定位問題

git clone git@github.com:UED/test.git 

git fetch origin    //取得遠程更新，這裏能夠看作是準備要取了

git merge origin/master  //把更新的內容合併到本地分支/master  


git remote -v //查看當前項目遠程鏈接的是哪一個倉庫地址。
  
git push -u origin master //    將本地的項目提交到遠程倉庫中。

git push -u origin master -f // 強制提交

git commit --amend 修改上一次 commit

拋棄本地全部的修改，回到遠程倉庫的狀態。
git fetch --all && git reset --hard origin/master

        git clone 地址  clone
        git branch 查看分支
        git branch daily/0.0.1 建立分支

        # 切換分支，格式爲 daily/x.y.z
        git checkout daily/0.0.3
        # 提交代碼
        git pull
        git add *
        git commit -m 'feat: 完成了某個新功能'

        # 將代碼push到gitlab daily環境
        git push origin daily/0.0.3

        # 打publish tag將代碼發佈到CDN
        --tag 建立一個里程碑
        git tag publish/0.0.3
        git push origin publish/0.0.3

代碼中的註釋類型前綴

TODO: 有功能待實現。此時須要對將要實現的功能進行簡單說明。
FIXME: 該處代碼運行正常，但可能因爲時間趕或者其餘緣由，須要修正。此時須要對如何修正進行簡單說明。
HACK: 爲修正某些問題而寫的不太好或者使用了某些詭異手段的代碼。此時須要對思路或詭異手段進行描述。

# 標題行：50個字符之內，描述主要變動內容
    #
    # 主體內容：更詳細的說明文本，建議72個字符之內。 須要描述的信息包括:
    #
    # * 爲何這個變動是必須的? 它多是用來修復一個bug，增長一個feature，提高性能、可靠性、穩定性等等
    # * 他如何解決這個問題? 具體描述解決問題的步驟
    # * 是否存在反作用、風險?
    #
    # 尾部：若是須要的化能夠添加一個連接到issue地址或者其它文檔，或者關閉某個issue。