代碼審查規(guī)范

1、-可編輯修改-代碼審查規(guī)范1. Code Review 目的CodeCode ReviewReview 是一種用來(lái)確認(rèn)方案設(shè)計(jì)和代碼實(shí)現(xiàn)的質(zhì)量保證機(jī)制，通過(guò)這個(gè)機(jī)制我們可以對(duì) 代碼、測(cè)試過(guò)程 和 注釋 進(jìn)行檢查。CodeCode ReviewReview 主要用來(lái)在軟件工程過(guò)程中改進(jìn)代碼質(zhì)量，通過(guò)CodeCode ReviewReview 可以達(dá)到如下目的：在項(xiàng)目早期就能夠發(fā)現(xiàn)代碼中的BUGBUG。幫助初級(jí)開發(fā)人員學(xué)習(xí)高級(jí)開發(fā)人員的經(jīng)驗(yàn)，達(dá)到知識(shí)共享。避免開發(fā)人員犯一些很常見，很普通的錯(cuò)誤。保證項(xiàng)目組人員的良好溝通。項(xiàng)目或產(chǎn)品的代碼更容易維護(hù)。2. Code Review 的前提條件代碼提交審

2、核前，開發(fā)者 必須確保代碼符合如下條件，審核者 需要確保所有前提條件都已滿足方可開始審查，同時(shí)也是審查的主要檢查點(diǎn)。*所有代碼注釋清晰，語(yǔ)法正確，編譯通過(guò)。*日志代碼完整，業(yè)務(wù)日志、系統(tǒng)日志分開，中文描述，脫敏處理，狀態(tài)變更， 全部清晰明確。*測(cè)試代碼覆蓋全部分支和流程，暫時(shí)統(tǒng)一使用工具EmmaEmma （各編譯器可下載對(duì)應(yīng)插件）進(jìn)行 CoverageCoverage CheckCheck-可編輯修改-項(xiàng)目引用關(guān)系明確，依賴關(guān)系清晰，配置文件描述3. Code Review 的審查范圍代碼的一致性、編碼風(fēng)格、代碼的安全問(wèn)題、脫敏問(wèn)題、代碼冗余、是否正確設(shè)計(jì)以符 合設(shè)計(jì)要求(性能、功能)與設(shè)計(jì)文

3、檔相同等等。3.1、完整性檢查(Completeness )代碼是否完全實(shí)現(xiàn)了設(shè)計(jì)文檔中所涉及的所有流程和功能點(diǎn)代碼是否已包含所有所需的業(yè)務(wù)日志、系統(tǒng)日志、異常日志，日志內(nèi)容是否完 整，日志文件配置是否正確。代碼是否使用緩存等，配置信息是否正確可配置。代碼中是否存在任何沒(méi)有定義或沒(méi)有引用到的變量、常數(shù)或數(shù)據(jù)類型等3.2、一致性檢查(Consistency)代碼的邏輯是否符合設(shè)計(jì)文檔代碼中使用的格式、符號(hào)、結(jié)構(gòu)等風(fēng)格是否保持一致3.3、正確性檢查(Correctness)*代碼是否符合制定的標(biāo)準(zhǔn)*所有的變量都被正確定義和使用*所有的注釋都是準(zhǔn)確的-可編輯修改-所有的程序調(diào)用都使用了正確的參數(shù)個(gè)數(shù)

4、3.4、可修改性檢查(Modifiability )代碼涉及到的常量是否易于修改( (如使用配置、定義為類常量、使用專門的常量類等) )代碼中是否包含了交叉說(shuō)明或數(shù)據(jù)字典，以描述程序是如何對(duì)變量和常量進(jìn)行 訪問(wèn)的代碼是否只有一個(gè)出口和一個(gè)入口(嚴(yán)重的異常處理除外)3.5、可預(yù)測(cè)性檢查(Predictability)代碼所用的開發(fā)語(yǔ)言是否具有定義良好的語(yǔ)法和語(yǔ)義是否代碼避免了依賴于開發(fā)語(yǔ)言缺省提供的功能代碼是否無(wú)意中陷入了死循環(huán)代碼是否避免了無(wú)窮遞歸3.6、健壯性檢查(Robustness)代碼是否采取措施避免運(yùn)行時(shí)錯(cuò)誤(如數(shù)組邊界溢出、被零除、值越界、堆棧 溢出等)3.7、結(jié)構(gòu)性檢查(Stru

5、cturedness )程序的每個(gè)功能是否都作為一個(gè)可辯識(shí)的代碼塊存在*循環(huán)是否只有一個(gè)入口3.8、可追溯性檢查(Traceability )代碼是否對(duì)每個(gè)程序進(jìn)行了唯一標(biāo)識(shí)-可編輯修改-是否有一個(gè)交叉引用的框架可以用來(lái)在代碼和開發(fā)文檔之間相互對(duì)應(yīng)代碼是否包括一個(gè)修訂歷史記錄，記錄中對(duì)代碼的修改和原因都有記錄4是否所有的安全功能都有標(biāo)識(shí)3.9、可理解性檢查(Understandability )注釋是否足夠清晰的描述每個(gè)子程序是否使用到不明確或不必要的復(fù)雜代碼，它們是否被清楚的注釋使用一些統(tǒng)一的格式化技巧(如縮進(jìn)、空白等)用來(lái)增強(qiáng)代碼的清晰度是否在定義命名規(guī)則時(shí)采用了便于記憶，反映類型等方法每

6、個(gè)變量都定義了合法的取值范圍代碼中的算法是否符合開發(fā)文檔中描述的數(shù)學(xué)模型3.10、可驗(yàn)證性檢查(Verifiability)代碼中的實(shí)現(xiàn)技術(shù)是否便于測(cè)試測(cè)試代碼是否正確，是否覆蓋所有流程4. Code Review 的步驟目前 CodeCode ReviewReview 步驟暫定如下，試行一段時(shí)間再根據(jù)問(wèn)題做調(diào)整-可編輯修改-1.代碼編寫者 和代碼審核者 坐在一起，由代碼編寫者 按照設(shè)計(jì)文檔中的用例依次講解自己所寫的代碼和相關(guān)邏輯，可采用從前端到后臺(tái)的方式，例如從WebWeb 層-DAO-DAO 層。2.代碼審核者 在此過(guò)程中可以隨時(shí)提出自己的疑問(wèn)，同時(shí)積極發(fā)現(xiàn)隱藏的 bugbug ； 代碼編

7、寫者和代碼審核者都要對(duì)這些 bugbug 記錄在案， 代碼編寫者修改后再次提 交審核， 代碼審核者對(duì)應(yīng) bubug g記錄進(jìn)行回驗(yàn)。3.代碼講解完畢后，代碼審核者 給自己安排幾個(gè)小時(shí)再對(duì)代碼審核一遍。代碼需要一行一行靜下心看。同時(shí)代碼又要全面的看，以確保代碼整體上設(shè)計(jì)優(yōu)良。4.代碼審核者 根據(jù)審核的結(jié)果編寫代碼審核結(jié)果”并將審核記錄”和 審核結(jié)果”提交至 GITGIT，審核記錄 和 審核結(jié)果 參見附錄 I I 審核記錄、附錄 IIII 審核結(jié)果。5.代碼編寫者 GITGIT pullpull 并根據(jù) 審核結(jié)果”給出的修改意見，修改好代碼，有不清 楚的地方可積極向代碼審核者提出。6.代碼編寫者

8、bugbug fixfix 等全部修改完成后提交代碼審核者 再次進(jìn)行審核，通過(guò)審核則代碼審核者更新本次審查結(jié)果并提交至GITGIT，審核通過(guò)對(duì)代碼不能再進(jìn)行修改，任何已通過(guò)審核的代碼修改必須重新進(jìn)行審核流程。7.代碼審核者把 CodeCode ReviewReview 中發(fā)現(xiàn)的有價(jià)值的問(wèn)題更新到”代碼規(guī)范 的文檔中，對(duì)于特別值得提醒的問(wèn)題可群發(fā)emailemail 或 QQQQ 給所有技術(shù)人員。-可編輯修改-5. Code Review 標(biāo)準(zhǔn)代碼審查的基礎(chǔ)是我們的設(shè)計(jì)文檔規(guī)范、代碼規(guī)范、日志規(guī)范、測(cè)試代碼規(guī)范，針對(duì)新增的業(yè)務(wù)場(chǎng)景和設(shè)計(jì)尚未有規(guī)范對(duì)應(yīng)時(shí)應(yīng)先確立規(guī)范然后再進(jìn)行代碼審核流程。6. C

9、ode Review 注意點(diǎn)6.1. 經(jīng)常進(jìn)行 Code Review要 ReviewReview 的代碼越多，那么要重構(gòu)，重寫的代碼就會(huì)越多。而越不被代碼編寫者接受的建議也會(huì)越多，唾沫口水戰(zhàn)也會(huì)越多。建議每一個(gè)功能，每一個(gè)用例完成后都可以進(jìn)行審核，將大任務(wù)拆分為小任務(wù)進(jìn)行。程序員代碼寫得時(shí)候越長(zhǎng)，程序員就會(huì)在代碼中加入越來(lái)越多的個(gè)人的東西。越接近軟件發(fā)布的最終期限，代碼也就不能改得太多。6.2. Code Review 不要太正式，而且要短忘了那個(gè)代碼評(píng)審的 ChecklistChecklist 吧，走到你的同事座位跟前，像請(qǐng)師父一樣請(qǐng)他坐到你 的電腦面前，然后，花 5 5 分鐘給他講講你的

10、代碼， 給他另外一個(gè) 5 5 分鐘讓他給你的代碼 提提意見，這比什么都豐樓世碼Git push 審檢箝巨図審息申請(qǐng)代 6$弓審再：亍代阿寂-可編輯修改-好。而如果你用了一個(gè) ChecklistChecklist，讓這個(gè)事情表現(xiàn)得很正式的話，下面兩件事中必有一件事會(huì)發(fā)生：只有在 ChecklistChecklist 上存在的東西才會(huì)被 ReviewReview。CodeCode ReviewsReviews 變成了一種禮節(jié)性的東西， 你的同事會(huì)裝做很關(guān)心你的代碼，但其實(shí)他心里想著盡快地離開你。只有不正式的 CodeCode ReviewReview 才會(huì)讓你和評(píng)審者放輕松，人只有放松了，才會(huì)表現(xiàn)

11、得很真實(shí)，很真誠(chéng)。記住式，而只有在相互信任中通過(guò)相互的討論得到了有意義和有建設(shè)性的建議和意見，那才是最實(shí)在的。不然，作者和評(píng)審者的關(guān)系就會(huì)變成小偷和警察的關(guān)系。6.3. 盡可能的讓不同的人 Reivew 你的代碼如果可能的話，不要總是只找一個(gè)人來(lái) ReviewReview 你的代碼，不同的人有不同的思考方式， 有不同的見解，所以，不同的人可以全面的從各個(gè)方面評(píng)論你的代碼。但不要太多了,人多嘴雜反而適得其反，基本上來(lái)說(shuō)，不要超過(guò)3 3 個(gè)人，這是因?yàn)?，這是一個(gè)可以圍在一起討論的最大人員尺寸。下面是幾個(gè)優(yōu)點(diǎn)：從不同的方向評(píng)審代碼總是好的。會(huì)有更多的人幫你在日后維護(hù)你的代碼。這也是一個(gè)增加團(tuán)隊(duì)凝聚力

12、的方法。6.4. 保持積極的正面的態(tài)度程序員最大的問(wèn)題就是 自負(fù)”，尤其當(dāng)我們 ReivewReivew 別人的代碼的時(shí)候，我已經(jīng)見過(guò)無(wú) 數(shù)的場(chǎng)面，ReviewReview 只不過(guò)是一種形-可編輯修改-程序員在 CodeCode ReviewReview 的時(shí)候，開始抨擊別人的代碼，質(zhì)疑別人的能力。太可笑了，我分析了一下，這類的程序員其實(shí)并沒(méi)有什么本事，因?yàn)樗麄冎肛?zé)對(duì)方的目 的是想告訴大家自己有多么的牛，靠這種手段來(lái)表現(xiàn)自己的程序員，其實(shí)是就是傳說(shuō)中 所說(shuō)的 半瓶水”。所以，無(wú)論是代碼編寫者，還是代碼審核者，都需要一種積極向上 的正面的態(tài)度，編寫者需要能夠虛心接受別人的建議，因?yàn)閯e人的建議是為

13、了讓你做得更好；審核者也需要以一種積極的正面的態(tài)度向編寫者提意見, 壕里的戰(zhàn)友。記住，你不是一段代碼，你是一個(gè)人！6.5. 學(xué)會(huì)享受 Code Reivew這可能是最重要的一個(gè)提示了，如果你到了一個(gè)人人都喜歡CodeCode ReivewReivew 的團(tuán)隊(duì)，那么，你會(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ì)。7. Code Review 操作目前我們將 CodeCode ReviewReview 分為兩個(gè)

14、階段，開發(fā)互審 和上級(jí)審查 兩個(gè)階段。7.1 開發(fā)互審任意兩名開發(fā)人員（建議不要固定配對(duì)，避免思維定勢(shì)）進(jìn)行交叉代碼審查，代碼編寫者準(zhǔn)備所開發(fā)的代碼相關(guān)的全部資料列表，包括需求、設(shè)計(jì)文檔、代碼工程、類、方法、配置文件、數(shù)據(jù)庫(kù)修改、數(shù)據(jù)修改等全部資料的版本號(hào)等詳細(xì)信息，向代碼審因?yàn)槟?可編輯修改-查者全面介紹代碼的目標(biāo)和設(shè)計(jì)實(shí)現(xiàn)。代碼審查者 按照需求文檔、設(shè)計(jì)文檔、開發(fā)規(guī)范進(jìn)行代碼（業(yè)務(wù)、日志、測(cè)試）審查， 代碼審查者 將審查結(jié)果提交至 GITGIT，出現(xiàn)的 問(wèn)題由 代碼編寫者 進(jìn)行修改并由 代碼審查者 復(fù)審，復(fù)審結(jié)果提交至 GITGIT 保留。代碼 審查者 對(duì)所審查的代碼負(fù)責(zé)。7.2 上級(jí)檢查

15、開發(fā)互審?fù)瓿珊?，由上?jí)進(jìn)行上級(jí)審查，流程與開發(fā)互審相同，對(duì)于三次復(fù)審仍未通過(guò) 的代碼需要代碼編寫者組內(nèi)進(jìn)行檢討問(wèn)題原因，并書面列出改進(jìn)計(jì)劃。7.3 沖突解決當(dāng)開發(fā)互審時(shí)對(duì)于檢查內(nèi)容出現(xiàn)爭(zhēng)議時(shí)由上級(jí)進(jìn)行協(xié)調(diào)解決或逐級(jí)向上協(xié)調(diào)解決。當(dāng)上級(jí)審查 時(shí)出現(xiàn)爭(zhēng)議時(shí)逐級(jí)向上協(xié)調(diào)解決。所有問(wèn)題解決原則為公司利益、團(tuán)隊(duì)利益、業(yè)務(wù)需求、設(shè)計(jì)文檔、規(guī)范文檔等為參考標(biāo)準(zhǔn)。附錄 I 審核記錄審核記錄如同修改記錄一樣，直接記錄入代碼頭部，代碼審核者 修改審核記錄后提交代碼至 GITGIT 參考即可。之后的審核可以基于兩次審核間的變更利用對(duì)比工具進(jìn)行增量審核。 可參考如下示例類：n n gp_comgp_com monmo

16、n /src/mai/src/mai n/java/com/heepay/file/FileUtils.javan/java/com/heepay/file/FileUtils.java代碼示例：/*名稱：文件操作工具類*創(chuàng)建者：王曉 *-可編輯修改-創(chuàng)建時(shí)間：2016-06-21*創(chuàng)建描述：實(shí)現(xiàn)文件的創(chuàng)建、刪除、復(fù)制、壓縮、解壓以及目錄的創(chuàng)建、刪除、復(fù)制、壓縮解壓等功能*修改者：李宗杰*修改時(shí)間：2016-08-08*修改描述：添加注釋和代碼審核信息*修改者：*修改時(shí)間：*修改描述：*審核者：-可編輯修改-一行寫不下再次一行*再來(lái)一行*審核者：李宗杰*審核時(shí)間：2016-08-08*審核描述

17、：審核不通過(guò)，log 沒(méi)有使用 Iog4j2*審核者：*審核時(shí)間：*審核描述：*/附錄 II 審核結(jié)果審核結(jié)果建議以表格的形式描述，每個(gè)問(wèn)題分別列出，可以通過(guò)標(biāo)注行號(hào)來(lái)具體指明位置，給出合理的修改意見并說(shuō)明標(biāo)準(zhǔn)。為了方便記錄和查詢以及代碼編寫者修改和復(fù)審，建議審核結(jié)果寫入 commitcommit messagemessage 中，由于 commitcommit messagemessage 只能提交文本， 我們以軟表格的形式描述。對(duì)于 commitcommit messagemessage 的書寫規(guī)范，查看參考。格式：docs （代碼審核）：審核通過(guò)docs （代碼審核）：審核失敗可列出 2.問(wèn)題名稱問(wèn)題：?jiǎn)栴}內(nèi)