CodeReview規(guī)范有哪些，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。
成都創(chuàng)新互聯(lián)長(zhǎng)期為上1000家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開(kāi)放共贏平臺(tái)，與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為潘集企業(yè)提供專業(yè)的成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站，潘集網(wǎng)站改版等技術(shù)服務(wù)。擁有10多年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開(kāi)發(fā)。
提高代碼質(zhì)量，及早發(fā)現(xiàn)潛在缺陷，降低修改/彌補(bǔ)缺陷的成本
促進(jìn)團(tuán)隊(duì)內(nèi)部知識(shí)共享，提高團(tuán)隊(duì)整體水平
評(píng)審過(guò)程對(duì)于評(píng)審人員來(lái)說(shuō)，也是一種思路重構(gòu)的過(guò)程，幫助更多的人理解系統(tǒng)
是一個(gè)傳遞知識(shí)的手段，可以讓其它并不熟悉代碼的人知道作者的意圖和想法，從而可以在以后輕松維護(hù)代碼
可以被用來(lái)確認(rèn)自己的設(shè)計(jì)和實(shí)現(xiàn)是一個(gè)清楚和簡(jiǎn)單的
鼓勵(lì)相互學(xué)習(xí)對(duì)方的長(zhǎng)處和優(yōu)點(diǎn)
高效迅速完成Code Review
采用Git Flow + Pull Request（PR）模式來(lái)做Code Review。
Pull Request 的說(shuō)明
任務(wù)完成才能提交PR
嚴(yán)禁一個(gè)PR里面有多個(gè)任務(wù)，除非它們是緊密關(guān)聯(lián)的
PR提交之后只允許針對(duì)Review發(fā)現(xiàn)問(wè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)用簡(jiǎn)短但是足夠說(shuō)明問(wèn)題的語(yǔ)言（理想是控制在3句話之內(nèi)）來(lái)描述： 你改動(dòng)了什么，解決了什么問(wèn)題，需要代碼審查的人留意那些影響比較大的改動(dòng)。特別需要留意，如果對(duì)基礎(chǔ)、公共的組件進(jìn)行了改動(dòng)，一定要另起一行特別說(shuō)明。
PR應(yīng)該在1~2個(gè)工作日內(nèi)被合并或者被拒絕
發(fā)起Pull Request以后，請(qǐng)將Pull Request的鏈接通過(guò)Email發(fā)給代碼審核者，以此通知對(duì)方及時(shí)進(jìn)行審核。(BUG修復(fù)類當(dāng)日必須完成合并或者拒絕，功能類或者覺(jué)得有重大調(diào)整需要會(huì)議Review必須在郵件中明確時(shí)間和會(huì)議人員)
Code Review主要檢查代碼中是否存在以下方面問(wèn)題：
代碼的一致性、編碼風(fēng)格、代碼的安全問(wèn)題、代碼冗余、是否正確設(shè)計(jì)以滿足需求（功能、性能）等等
完整性檢查
代碼是否完全實(shí)現(xiàn)了設(shè)計(jì)文檔中提出的功能需求
代碼是否已按照設(shè)計(jì)文檔進(jìn)行了集成和Debug
代碼是否已創(chuàng)建了需要的數(shù)據(jù)庫(kù)，包括正確的初始化數(shù)據(jù)
代碼中是否存在任何沒(méi)有定義或沒(méi)有引用到的變量、常數(shù)或數(shù)據(jù)類型
一致性檢查
代碼的邏輯是否符合設(shè)計(jì)文檔
代碼中使用的格式、符號(hào)、結(jié)構(gòu)等風(fēng)格是否保持一致
正確性檢查
代碼是否符合制定的標(biāo)準(zhǔn)
所有的變量都被正確定義和使用
所有的注釋都是準(zhǔn)確的
所有的程序調(diào)用都使用了正確的參數(shù)個(gè)數(shù)
可修改性檢查
代碼涉及到的常量是否易于修改(如使用配置、定義為類常量、使用專門的常量類等)
代碼中是否包含了交叉說(shuō)明或數(shù)據(jù)字典，以描述程序是如何對(duì)變量和常量進(jìn)行訪問(wèn)的
代碼是否只有一個(gè)出口和一個(gè)入口（嚴(yán)重的異常處理除外）
可預(yù)測(cè)性檢查
代碼所用的開(kāi)發(fā)語(yǔ)言是否具有定義良好的語(yǔ)法和語(yǔ)義
是否代碼避免了依賴于開(kāi)發(fā)語(yǔ)言缺省提供的功能
代碼是否無(wú)意中陷入了死循環(huán)
代碼是否是否避免了無(wú)窮遞歸
健壯性檢查
異常處理和清理（釋放）資源
代碼是否采取措施避免運(yùn)行時(shí)錯(cuò)誤（如數(shù)組邊界溢出、被零除、值越界、堆棧溢出等）
結(jié)構(gòu)性檢查
程序的每個(gè)功能是否都作為一個(gè)可辯識(shí)的代碼塊存在
循環(huán)是否只有一個(gè)入口
可追溯性檢查
代碼是否對(duì)每個(gè)程序進(jìn)行了唯一標(biāo)識(shí)
是否有一個(gè)交叉引用的框架可以用來(lái)在代碼和開(kāi)發(fā)文檔之間相互對(duì)應(yīng)
代碼是否包括一個(gè)修訂歷史記錄，記錄中對(duì)代碼的修改和原因都有記錄
是否所有的安全功能都有標(biāo)識(shí)
可理解性檢查
注釋是否足夠清晰的描述每個(gè)子程序
是否使用到不明確或不必要的復(fù)雜代碼，它們是否被清楚的注釋
使用一些統(tǒng)一的格式化技巧（如縮進(jìn)、空白等）用來(lái)增強(qiáng)代碼的清晰度
是否在定義命名規(guī)則時(shí)采用了便于記憶，反映類型等方法
每個(gè)變量都定義了合法的取值范圍
代碼中的算法是否符合開(kāi)發(fā)文檔中描述的數(shù)學(xué)模型
可驗(yàn)證性檢查
代碼中的實(shí)現(xiàn)技術(shù)是否便于測(cè)試
可重用性
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ù)端開(kāi)發(fā)必須遵循阿里巴巴Java開(kāi)發(fā)手冊(cè)（終極版）,IDEA中安裝相關(guān)插件有告警提示不允許提交合并
代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UC依次講解自己負(fù)責(zé)的代碼和相關(guān)邏輯，從Web層->DAO層；
代碼審核者在此過(guò)程中可以隨時(shí)提出自己的疑問(wèn)，同時(shí)積極發(fā)現(xiàn)隱藏的bug；對(duì)這些bug記錄在案。
代碼講解完畢后，代碼審核者給自己安排幾個(gè)小時(shí)再對(duì)代碼審核一遍。代碼需要一行一行靜下心看。同時(shí)代碼又要全面的看，以確保代碼整體上設(shè)計(jì)優(yōu)良。
代碼審核者根據(jù)審核的結(jié)果編寫“代碼審核報(bào)告”，“審核報(bào)告”中記錄發(fā)現(xiàn)的問(wèn)題及修改建議，然后把“審核報(bào)告”發(fā)送給相關(guān)人員。
代碼編寫者根據(jù)“代碼審核報(bào)告”給出的修改意見(jiàn)，修改好代碼，有不清楚的地方可積極向代碼審核者提出。
代碼編寫者 bug fix完畢之后給出反饋。
代碼審核者把Code Review中發(fā)現(xiàn)的有價(jià)值的問(wèn)題更新到"代碼審核規(guī)范"的文檔中，對(duì)于特別值得提醒的問(wèn)題可群發(fā)email給所有技術(shù)人員。
備注：
Code Review必備的文檔：
“Code Review規(guī)范”文檔：記錄代碼應(yīng)該遵循的標(biāo)準(zhǔn)。
代碼審核者根據(jù)這些標(biāo)準(zhǔn)來(lái)Code Review代碼，同時(shí)在Code Review過(guò)程中不斷完善該文檔。
評(píng)審規(guī)范和標(biāo)準(zhǔn)
在CR前設(shè)計(jì)確定評(píng)審規(guī)范和標(biāo)準(zhǔn)是必要，通過(guò)規(guī)范和標(biāo)準(zhǔn)我們?cè)趯彶檫^(guò)程中可以有據(jù)可依，有理可循，而且還可以做到標(biāo)準(zhǔn)統(tǒng)一。
選擇CR活動(dòng)的參與者
在CR開(kāi)始前，必須把本次CR活動(dòng)的對(duì)象、審查內(nèi)容以及審查的規(guī)范和標(biāo)準(zhǔn)通過(guò)email通報(bào)給所有的參與者。
選擇CR活動(dòng)的實(shí)施方式
CR活動(dòng)有很多形式可供我們選擇，我們可以根據(jù)實(shí)際情況選擇桌面式CR、演示講解式CR、一對(duì)一的座位CR等等。(一般按新增功能桌面式CR、里程碑功能演示講解式CR、BUG修復(fù)一對(duì)一的座位CR)
充分的事前準(zhǔn)備，只是做好CR活動(dòng)的前提，在CR實(shí)施過(guò)程中，我們要做好以下工作。
準(zhǔn)確記錄
對(duì)于CR過(guò)程發(fā)現(xiàn)的問(wèn)題，我們必須清晰準(zhǔn)確的記錄，可以使用問(wèn)題點(diǎn)記錄單，明確記錄的項(xiàng)目和內(nèi)容。
講解與提問(wèn)
CR過(guò)程中，要采用代碼作者講解和審查者提問(wèn)方式。審查者不能只在發(fā)現(xiàn)問(wèn)題時(shí)提問(wèn)，同時(shí)也要根據(jù)本次審查的內(nèi)容要求代碼作者對(duì)某個(gè)特定問(wèn)題的講解。
逐項(xiàng)審查
對(duì)事前確定的審查內(nèi)容，要逐項(xiàng)審查，不能因?yàn)闀r(shí)間不足等因素一掃而過(guò)。
注意氣氛
實(shí)施審查時(shí)，要營(yíng)造一個(gè)討論問(wèn)題、解決問(wèn)題的氛圍，不能把審查會(huì)搞成批判會(huì)，這樣會(huì)影響相關(guān)人員的積極性。
確認(rèn)發(fā)現(xiàn)的問(wèn)題 CR結(jié)束后，對(duì)發(fā)現(xiàn)的問(wèn)題，首先需要確定以下內(nèi)容。
問(wèn)題點(diǎn)的難易程度以及影響的范圍；
解決問(wèn)題的責(zé)任者和問(wèn)題點(diǎn)修正結(jié)果的確認(rèn)者；
解決問(wèn)題點(diǎn)的時(shí)限。
修正問(wèn)題責(zé)任者 對(duì)于修正問(wèn)題責(zé)任者，在問(wèn)題點(diǎn)的修正過(guò)程中，要三方面內(nèi)容的記錄。問(wèn)題點(diǎn)的原因；
解決問(wèn)題點(diǎn)的對(duì)策；
修正的內(nèi)容。
修正結(jié)果確認(rèn)者做為修正結(jié)果的確認(rèn)者，必須按照事前約定的時(shí)限及時(shí)的對(duì)修正結(jié)果進(jìn)行全面的確認(rèn)
經(jīng)常進(jìn)行Code Review
（1）要Review的代碼越多，那么要重構(gòu)，重寫的代碼就會(huì)越多。而越不被程序作者接受的建議也會(huì)越多，唾沫口水戰(zhàn)也會(huì)越多。
（2）程序員代碼寫得時(shí)候越長(zhǎng)，程序員就會(huì)在代碼中加入越來(lái)越多的個(gè)人的東西。
（3）越接近軟件發(fā)布的最終期限，代碼也就不能改得太多。
Code Review不要太正式，而且要短
忘了那個(gè)代碼評(píng)審的Checklist吧，走到你的同事座位跟前，像請(qǐng)師父一樣請(qǐng)他坐到你的電腦面前，然后，花5分鐘給他講講你的代碼，給他另外一個(gè)5分鐘讓他給你的代碼提提意見(jiàn)，這比什么都好。而如果你用了一個(gè)Checklist，讓這個(gè)事情表現(xiàn)得很正式的話，下面兩件事中必有一件事會(huì)發(fā)生：
（1）只有在Checklist上存在的東西才會(huì)被Review。
（2）Code Reviews 變成了一種禮節(jié)性的東西，你的同事會(huì)裝做很關(guān)心你的代碼，但其實(shí)他心里想著盡快地離開(kāi)你。
只有不正式的Code Review才會(huì)讓你和評(píng)審者放輕松，人只有放松了，才會(huì)表現(xiàn)得很真實(shí)，很真誠(chéng)。記住Review只不過(guò)是一種形式，而只有在相互信任中通過(guò)相互的討論得到了有意義和有建設(shè)性的建議和意見(jiàn)，那才是最實(shí)在的。不然，作者和評(píng)審者的關(guān)系就會(huì)變成小偷和警察的關(guān)系。
盡可能的讓不同的人Review你的代碼
如果可能的話，不要總是只找一個(gè)人來(lái)Review你的代碼，不同的人有不同的思考方式，有不同的見(jiàn)解，所以，不同的人可以全面的從各個(gè)方面評(píng)論你的代碼。
但不要太多了，人多嘴雜反而適得其反，基本上來(lái)說(shuō)，不要超過(guò)3個(gè)人，這是因?yàn)?，這是一個(gè)可以圍在一起討論的最大人員尺寸。
下面是幾個(gè)優(yōu)點(diǎn)：
（1）從不同的方向評(píng)審代碼總是好的。
（2）會(huì)有更多的人幫你在日后維護(hù)你的代碼。
（3）這也是一個(gè)增加團(tuán)隊(duì)凝聚力的方法。
保持積極的正面的態(tài)度
程序員最大的問(wèn)題就是“自負(fù)”，尤其當(dāng)我們Review別人的代碼的時(shí)候，我已經(jīng)見(jiàn)過(guò)無(wú)數(shù)的場(chǎng)面，程序員在Code Review的時(shí)候，開(kāi)始抨擊別人的代碼，質(zhì)疑別人的能力。太可笑了，我分析了一下，這類的程序員其實(shí)并沒(méi)有什么本事，因?yàn)樗麄冎肛?zé)對(duì)方的目的是想告訴大家自己有多么的牛，靠這種手段來(lái)表現(xiàn)自己的程序員，其實(shí)是就是傳說(shuō)中所說(shuō)的“半瓶水”。
所以，無(wú)論是代碼作者，還是評(píng)審者，都需要一種積極向上的正面的態(tài)度，作者需要能夠虛心接受別人的建議，因?yàn)閯e人的建議是為了讓你做得更好；評(píng)審者也需要以一種積極的正面的態(tài)度向作者提意見(jiàn)，因?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ì)。
看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對(duì)創(chuàng)新互聯(lián)的支持。
重慶分公司
重慶分公司
