開(kāi)發(fā)規(guī)范 | 代碼審核規(guī)范
該規(guī)范主要參考《谷歌的代碼評(píng)審指南》
一、開(kāi)發(fā)者
不應(yīng)該在 CI 內(nèi)同時(shí)包含主要風(fēng)格的改動(dòng)與其他代碼的修改，這樣會(huì)導(dǎo)致難以看出 CI 到底做出什么改動(dòng)
格式化 commit message
優(yōu)勢(shì)：
提供更多的歷史信息，方便快速瀏覽;
可以過(guò)濾某些 commit（比如文檔改動(dòng)），便于查找信息;
可以直接從 commit 生成 change log。
格式：
commit message 都包含三個(gè)部分：Header（必需）、Body（可選）、Footer（可選）
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Header 部分只有一行，三個(gè)字段：type（必需）、scope（可選）、subject（必需）
type 用于說(shuō)明commit的類別，只允許使用下面7個(gè)標(biāo)識(shí)
feat：新功能（feature）
fix：修復(fù)bug
docs：文檔
style：格式（不影響代碼運(yùn)行的變動(dòng)）
refactor：重構(gòu)（既不是新增功能，也不是修改bug的代碼變動(dòng)）
perf：提高性能的改動(dòng)，不改變邏輯
test：增加測(cè)試
build：構(gòu)造工具的或者外部依賴的改動(dòng)
ci：改變關(guān)于 ci 的配置、腳本或者依賴
chore：構(gòu)建過(guò)程或輔助工具的變更
revert：回退上一個(gè)版本
scope 用戶說(shuō)明 commit 影響的范圍，比如數(shù)據(jù)層、控制層、視圖層等
subject 是 commit 目的的簡(jiǎn)短描述，不超過(guò)50個(gè)字符
body 部分是對(duì)本次 commit 的詳細(xì)描述，可以分成多行
footer 部分只用于兩種情況：1、不兼容變動(dòng)；2、關(guān)閉issue
擴(kuò)展：如果你使用 IDEA 進(jìn)行編碼，可以是使用
git commit template插件來(lái)規(guī)范每次提交的 commit message 信息
格式化后的代碼 message 為：
feat(App): 增減排序算法
查看不用情況下的排序算法的區(qū)別
BREAKING CHANGE: 排序算法與上一個(gè)版本不兼容
Closes #123123
二、評(píng)審者
checklist
設(shè)計(jì)：代碼是否經(jīng)過(guò)精心設(shè)計(jì)并適合你的系統(tǒng)
功能：代碼是否符合開(kāi)發(fā)者意圖？
復(fù)雜性：代碼是否可以更簡(jiǎn)潔？未來(lái)其他開(kāi)發(fā)者接手時(shí)，代碼是否易于理解與易用？
測(cè)試：代碼是否經(jīng)過(guò)正確且設(shè)計(jì)良好的自動(dòng)化測(cè)試
命名：開(kāi)發(fā)人員是否為變量、類、方法等選擇了明確的名稱？
注釋：注釋是否清晰有效？
風(fēng)格：代碼是否遵循了代碼開(kāi)發(fā)規(guī)范
文檔：開(kāi)發(fā)人員是否也同步更新了相關(guān)文檔
在評(píng)論前加上“nit:”這樣的前綴，表明這是一個(gè)優(yōu)化性的建議，可以不影響本次上線
應(yīng)在一個(gè)工作日內(nèi)完成評(píng)審，并給出意見(jiàn)
評(píng)價(jià)只針對(duì)代碼和具體業(yè)務(wù)流程
三、小項(xiàng)目團(tuán)隊(duì)內(nèi)部采用輪換review的方式
通過(guò)團(tuán)隊(duì)內(nèi)部輪流review來(lái)幫助團(tuán)隊(duì)成員對(duì)項(xiàng)目整體流程和代碼的認(rèn)知，通過(guò)一次一次review來(lái)提高每個(gè)成員對(duì)整個(gè)項(xiàng)目的大體流程、細(xì)節(jié)的熟悉程度，減少因?yàn)椴皇煜ごa導(dǎo)致的重復(fù)邏輯開(kāi)發(fā)，減少寫(xiě)重復(fù)代碼的概率。
通過(guò)審核別人的代碼，也能發(fā)現(xiàn)一些自己的一些缺點(diǎn)，有則改之，無(wú)則加勉。