目標(biāo)和原則
- 提高代碼質(zhì)量摆碉，及早發(fā)現(xiàn)潛在缺陷奴艾，降低修改/彌補(bǔ)缺陷的成本
- 促進(jìn)團(tuán)隊(duì)內(nèi)部知識(shí)共享，提高團(tuán)隊(duì)整體水平
- 評(píng)審過程對(duì)于評(píng)審人員來說衙伶，也是一種思路重構(gòu)的過程，幫助更多的人理解系統(tǒng)
- 是一個(gè)傳遞知識(shí)的手段害碾，可以讓其它并不熟悉代碼的人知道作者的意圖和想法矢劲，從而可以在以后輕松維護(hù)代碼
- 可以被用來確認(rèn)自己的設(shè)計(jì)和實(shí)現(xiàn)是一個(gè)清楚和簡單的
- 鼓勵(lì)相互學(xué)習(xí)對(duì)方的長處和優(yōu)點(diǎn)
- 高效迅速完成Code Review
流程和規(guī)則
采用Git Flow + Pull Request（PR）模式來做Code Review。
Git Flow
Pull Request（PR）
Pull Request 的說明
- 任務(wù)完成才能提交PR
- 嚴(yán)禁一個(gè)PR里面有多個(gè)任務(wù)慌随，除非它們是緊密關(guān)聯(lián)的
- PR提交之后只允許針對(duì)Review發(fā)現(xiàn)問題再次提交代碼芬沉，除非有充足的理由躺同，嚴(yán)禁在同一個(gè)PR中再次提交其它任務(wù)的代碼
- 提交PR時(shí)候有一個(gè)描述框，內(nèi)容會(huì)自動(dòng)根據(jù)Commit的message合并而成丸逸。切記蹋艺，如果一次提交的內(nèi)容包含很多Commit，請(qǐng)不要使用自動(dòng)生成的描述黄刚。請(qǐng)用簡短但是足夠說明問題的語言（理想是控制在3句話之內(nèi)）來描述： 你改動(dòng)了什么捎谨，解決了什么問題，需要代碼審查的人留意那些影響比較大的改動(dòng)憔维。特別需要留意涛救，如果對(duì)基礎(chǔ)、公共的組件進(jìn)行了改動(dòng)业扒，一定要另起一行特別說明检吆。
- PR應(yīng)該在1~2個(gè)工作日內(nèi)被合并或者被拒絕
- 發(fā)起Pull Request以后，請(qǐng)將Pull Request的鏈接通過Email發(fā)給代碼審核者程储，以此通知對(duì)方及時(shí)進(jìn)行審核蹭沛。(BUG修復(fù)類當(dāng)日必須完成合并或者拒絕，功能類或者覺得有重大調(diào)整需要會(huì)議Review必須在郵件中明確時(shí)間和會(huì)議人員)
Code Review Checklist
Code Review主要檢查代碼中是否存在以下方面問題：
代碼的一致性虱肄、編碼風(fēng)格致板、代碼的安全問題、代碼冗余咏窿、是否正確設(shè)計(jì)以滿足需求（功能斟或、性能）等等
-
完整性檢查
- 代碼是否完全實(shí)現(xiàn)了設(shè)計(jì)文檔中提出的功能需求
- 代碼是否已按照設(shè)計(jì)文檔進(jìn)行了集成和Debug
- 代碼是否已創(chuàng)建了需要的數(shù)據(jù)庫，包括正確的初始化數(shù)據(jù)
- 代碼中是否存在任何沒有定義或沒有引用到的變量集嵌、常數(shù)或數(shù)據(jù)類型
-
一致性檢查
- 代碼的邏輯是否符合設(shè)計(jì)文檔
- 代碼中使用的格式萝挤、符號(hào)、結(jié)構(gòu)等風(fēng)格是否保持一致
-
正確性檢查
- 代碼是否符合制定的標(biāo)準(zhǔn)
- 所有的變量都被正確定義和使用
- 所有的注釋都是準(zhǔn)確的
- 所有的程序調(diào)用都使用了正確的參數(shù)個(gè)數(shù)
-
可修改性檢查
- 代碼涉及到的常量是否易于修改(如使用配置根欧、定義為類常量怜珍、使用專門的常量類等)
- 代碼中是否包含了交叉說明或數(shù)據(jù)字典，以描述程序是如何對(duì)變量和常量進(jìn)行訪問的
- 代碼是否只有一個(gè)出口和一個(gè)入口（嚴(yán)重的異常處理除外）
-
可預(yù)測性檢查
- 代碼所用的開發(fā)語言是否具有定義良好的語法和語義
- 是否代碼避免了依賴于開發(fā)語言缺省提供的功能
- 代碼是否無意中陷入了死循環(huán)
- 代碼是否是否避免了無窮遞歸
-
健壯性檢查
- 異常處理和清理（釋放）資源
- 代碼是否采取措施避免運(yùn)行時(shí)錯(cuò)誤（如數(shù)組邊界溢出凤粗、被零除酥泛、值越界、堆棧溢出等）
-
結(jié)構(gòu)性檢查
- 程序的每個(gè)功能是否都作為一個(gè)可辯識(shí)的代碼塊存在
- 循環(huán)是否只有一個(gè)入口
-
可追溯性檢查
- 代碼是否對(duì)每個(gè)程序進(jìn)行了唯一標(biāo)識(shí)
- 是否有一個(gè)交叉引用的框架可以用來在代碼和開發(fā)文檔之間相互對(duì)應(yīng)
- 代碼是否包括一個(gè)修訂歷史記錄嫌拣，記錄中對(duì)代碼的修改和原因都有記錄
- 是否所有的安全功能都有標(biāo)識(shí)
-
可理解性檢查
- 注釋是否足夠清晰的描述每個(gè)子程序
- 是否使用到不明確或不必要的復(fù)雜代碼柔袁，它們是否被清楚的注釋
- 使用一些統(tǒng)一的格式化技巧（如縮進(jìn)、空白等）用來增強(qiáng)代碼的清晰度
- 是否在定義命名規(guī)則時(shí)采用了便于記憶异逐，反映類型等方法
- 每個(gè)變量都定義了合法的取值范圍
- 代碼中的算法是否符合開發(fā)文檔中描述的數(shù)學(xué)模型
-
可驗(yàn)證性檢查
- 代碼中的實(shí)現(xiàn)技術(shù)是否便于測試
-
可重用性
- DRY（Do not Repeat Yourself）原則：同一代碼不應(yīng)該重復(fù)兩次以上
- 考慮可重用的服務(wù)捶索，功能和組件
- 考慮通用函數(shù)和類
-
可擴(kuò)展性
- 輕松添加功能，對(duì)現(xiàn)有代碼進(jìn)行最小的更改灰瞻。一個(gè)組件可以被更好的組件替換
-
安全性
- 進(jìn)行身份驗(yàn)證腥例，授權(quán)辅甥，輸入數(shù)據(jù)驗(yàn)證，避免諸如SQL注入和跨站腳本（XSS）等安全威脅 燎竖，加密敏感數(shù)據(jù)（密碼璃弄，信用卡信息等）
-
性能
- 使用合適的數(shù)據(jù)類型，例如StringBuilder底瓣，通用集合類
- 懶加載谢揪，異步和并行處理
- 緩存和會(huì)話/應(yīng)用程序數(shù)據(jù)
代碼檢查包括不局限于上述清單蕉陋，提交人應(yīng)在本地自我完成代碼格式捐凭、架構(gòu)設(shè)計(jì)、面向?qū)ο蠓治雠c設(shè)計(jì)等檢查凳鬓。
備注：
- Java服務(wù)端開發(fā)必須遵循阿里巴巴Java開發(fā)手冊(cè)（終極版）,IDEA中安裝相關(guān)插件有告警提示不允許提交合并
Code Review的步驟
- 代碼編寫者和代碼審核者坐在一起茁肠，由代碼編寫者按照UC依次講解自己負(fù)責(zé)的代碼和相關(guān)邏輯，從Web層->DAO層缩举；
- 代碼審核者在此過程中可以隨時(shí)提出自己的疑問垦梆，同時(shí)積極發(fā)現(xiàn)隱藏的bug；對(duì)這些bug記錄在案仅孩。
- 代碼講解完畢后托猩，代碼審核者給自己安排幾個(gè)小時(shí)再對(duì)代碼審核一遍。代碼需要一行一行靜下心看辽慕。同時(shí)代碼又要全面的看京腥，以確保代碼整體上設(shè)計(jì)優(yōu)良。
- 代碼審核者根據(jù)審核的結(jié)果編寫“代碼審核報(bào)告”溅蛉，“審核報(bào)告”中記錄發(fā)現(xiàn)的問題及修改建議公浪，然后把“審核報(bào)告”發(fā)送給相關(guān)人員。
- 代碼編寫者根據(jù)“代碼審核報(bào)告”給出的修改意見船侧，修改好代碼欠气，有不清楚的地方可積極向代碼審核者提出。
- 代碼編寫者 bug fix完畢之后給出反饋镜撩。
- 代碼審核者把Code Review中發(fā)現(xiàn)的有價(jià)值的問題更新到"代碼審核規(guī)范"的文檔中预柒，對(duì)于特別值得提醒的問題可群發(fā)email給所有技術(shù)人員。
備注：
Code Review必備的文檔：
“Code Review規(guī)范”文檔：記錄代碼應(yīng)該遵循的標(biāo)準(zhǔn)袁梗。
代碼審核者根據(jù)這些標(biāo)準(zhǔn)來Code Review代碼宜鸯，同時(shí)在Code Review過程中不斷完善該文檔。
Code Review的執(zhí)行
準(zhǔn)備階段
- 評(píng)審規(guī)范和標(biāo)準(zhǔn)
- 在CR前設(shè)計(jì)確定評(píng)審規(guī)范和標(biāo)準(zhǔn)是必要围段，通過規(guī)范和標(biāo)準(zhǔn)我們?cè)趯彶檫^程中可以有據(jù)可依顾翼，有理可循，而且還可以做到標(biāo)準(zhǔn)統(tǒng)一奈泪。
- 選擇CR活動(dòng)的參與者
- 在CR開始前适贸，必須把本次CR活動(dòng)的對(duì)象灸芳、審查內(nèi)容以及審查的規(guī)范和標(biāo)準(zhǔn)通過email通報(bào)給所有的參與者。
- 選擇CR活動(dòng)的實(shí)施方式
- CR活動(dòng)有很多形式可供我們選擇拜姿，我們可以根據(jù)實(shí)際情況選擇桌面式CR烙样、演示講解式CR、一對(duì)一的座位CR等等蕊肥。(一般按新增功能桌面式CR谒获、里程碑功能演示講解式CR、BUG修復(fù)一對(duì)一的座位CR)
實(shí)施階段
充分的事前準(zhǔn)備壁却，只是做好CR活動(dòng)的前提批狱，在CR實(shí)施過程中，我們要做好以下工作展东。
- 準(zhǔn)確記錄
- 對(duì)于CR過程發(fā)現(xiàn)的問題赔硫，我們必須清晰準(zhǔn)確的記錄，可以使用問題點(diǎn)記錄單盐肃，明確記錄的項(xiàng)目和內(nèi)容爪膊。
- 講解與提問
- CR過程中，要采用代碼作者講解和審查者提問方式砸王。審查者不能只在發(fā)現(xiàn)問題時(shí)提問推盛，同時(shí)也要根據(jù)本次審查的內(nèi)容要求代碼作者對(duì)某個(gè)特定問題的講解。
- 逐項(xiàng)審查
- 對(duì)事前確定的審查內(nèi)容谦铃，要逐項(xiàng)審查耘成，不能因?yàn)闀r(shí)間不足等因素一掃而過。
- 注意氣氛
- 實(shí)施審查時(shí)荷辕，要營造一個(gè)討論問題凿跳、解決問題的氛圍，不能把審查會(huì)搞成批判會(huì)疮方，這樣會(huì)影響相關(guān)人員的積極性控嗜。
事后跟蹤
- 確認(rèn)發(fā)現(xiàn)的問題 CR結(jié)束后，對(duì)發(fā)現(xiàn)的問題骡显，首先需要確定以下內(nèi)容疆栏。
- 問題點(diǎn)的難易程度以及影響的范圍；
- 解決問題的責(zé)任者和問題點(diǎn)修正結(jié)果的確認(rèn)者惫谤；
- 解決問題點(diǎn)的時(shí)限壁顶。
- 修正問題責(zé)任者 對(duì)于修正問題責(zé)任者，在問題點(diǎn)的修正過程中溜歪，要三方面內(nèi)容的記錄若专。問題點(diǎn)的原因；
- 解決問題點(diǎn)的對(duì)策蝴猪；
- 修正的內(nèi)容调衰。
修正結(jié)果確認(rèn)者做為修正結(jié)果的確認(rèn)者膊爪，必須按照事前約定的時(shí)限及時(shí)的對(duì)修正結(jié)果進(jìn)行全面的確認(rèn)
注意事項(xiàng)
- 經(jīng)常進(jìn)行Code Review
（1）要Review的代碼越多，那么要重構(gòu)嚎莉，重寫的代碼就會(huì)越多米酬。而越不被程序作者接受的建議也會(huì)越多，唾沫口水戰(zhàn)也會(huì)越多趋箩。
（2）程序員代碼寫得時(shí)候越長赃额，程序員就會(huì)在代碼中加入越來越多的個(gè)人的東西。
（3）越接近軟件發(fā)布的最終期限叫确，代碼也就不能改得太多跳芳。
- Code Review不要太正式，而且要短
忘了那個(gè)代碼評(píng)審的Checklist吧启妹，走到你的同事座位跟前筛严，像請(qǐng)師父一樣請(qǐng)他坐到你的電腦面前醉旦，然后饶米，花5分鐘給他講講你的代碼，給他另外一個(gè)5分鐘讓他給你的代碼提提意見车胡，這比什么都好檬输。而如果你用了一個(gè)Checklist，讓這個(gè)事情表現(xiàn)得很正式的話匈棘，下面兩件事中必有一件事會(huì)發(fā)生：
（1）只有在Checklist上存在的東西才會(huì)被Review丧慈。
（2）Code Reviews 變成了一種禮節(jié)性的東西，你的同事會(huì)裝做很關(guān)心你的代碼主卫，但其實(shí)他心里想著盡快地離開你逃默。
只有不正式的Code Review才會(huì)讓你和評(píng)審者放輕松，人只有放松了簇搅，才會(huì)表現(xiàn)得很真實(shí)完域，很真誠。記住Review只不過是一種形式瘩将，而只有在相互信任中通過相互的討論得到了有意義和有建設(shè)性的建議和意見吟税，那才是最實(shí)在的。不然姿现，作者和評(píng)審者的關(guān)系就會(huì)變成小偷和警察的關(guān)系肠仪。
- 盡可能的讓不同的人Review你的代碼
如果可能的話，不要總是只找一個(gè)人來Review你的代碼备典，不同的人有不同的思考方式异旧，有不同的見解，所以提佣，不同的人可以全面的從各個(gè)方面評(píng)論你的代碼吮蛹。
但不要太多了欲险，人多嘴雜反而適得其反，基本上來說匹涮，不要超過3個(gè)人天试，這是因?yàn)椋@是一個(gè)可以圍在一起討論的最大人員尺寸然低。
下面是幾個(gè)優(yōu)點(diǎn)：
（1）從不同的方向評(píng)審代碼總是好的喜每。
（2）會(huì)有更多的人幫你在日后維護(hù)你的代碼。
（3）這也是一個(gè)增加團(tuán)隊(duì)凝聚力的方法雳攘。
- 保持積極的正面的態(tài)度
程序員最大的問題就是“自負(fù)”带兜，尤其當(dāng)我們Review別人的代碼的時(shí)候，我已經(jīng)見過無數(shù)的場面吨灭，程序員在Code Review的時(shí)候刚照，開始抨擊別人的代碼，質(zhì)疑別人的能力喧兄。太可笑了无畔，我分析了一下，這類的程序員其實(shí)并沒有什么本事吠冤，因?yàn)樗麄冎肛?zé)對(duì)方的目的是想告訴大家自己有多么的牛浑彰，靠這種手段來表現(xiàn)自己的程序員，其實(shí)是就是傳說中所說的“半瓶水”拯辙。
所以郭变，無論是代碼作者，還是評(píng)審者涯保，都需要一種積極向上的正面的態(tài)度诉濒，作者需要能夠虛心接受別人的建議，因?yàn)閯e人的建議是為了讓你做得更好夕春；評(píng)審者也需要以一種積極的正面的態(tài)度向作者提意見未荒，因?yàn)槟鞘呛湍阍谝粋€(gè)戰(zhàn)壕里的戰(zhàn)友。記住撇他，你不是一段代碼茄猫，你是一個(gè)人！
- 學(xué)會(huì)享受Code Review
這可能是最重要的一個(gè)提示了困肩，如果你到了一個(gè)人人都喜歡Code Review的團(tuán)阿划纽，那么，你會(huì)進(jìn)入到一個(gè)生機(jī)勃勃的地方锌畸，在那里勇劣，每個(gè)人都能寫出質(zhì)量非常好的代碼，在那里，你不需要經(jīng)理的管理比默，團(tuán)隊(duì)會(huì)自適應(yīng)一切變化幻捏，他們相互學(xué)習(xí)，相互幫助命咐，不僅僅是寫出好的代碼篡九，而且團(tuán)隊(duì)和其中的每個(gè)人都會(huì)自動(dòng)進(jìn)化，最關(guān)鍵的是醋奠，這個(gè)是一個(gè)團(tuán)隊(duì)榛臼。
