建站
咨詢
售后
建站咨詢
新聞中心
1．關(guān)于Code Review
創(chuàng)新互聯(lián)建站主營伊州網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,成都App制作,伊州h5重慶小程序開發(fā)搭建,伊州網(wǎng)站營銷推廣歡迎伊州等地區(qū)企業(yè)咨詢
1.1 Code Review的目的
Code Review主要用來在軟件工程過程中改進(jìn)代碼質(zhì)量，通過Code Review可以達(dá)到如下目的目的：
（1）在項(xiàng)目早期就能夠發(fā)現(xiàn)代碼中的BUG
（2）幫助初級開發(fā)人員學(xué)習(xí)高級開發(fā)人員的經(jīng)驗(yàn)，達(dá)到知識共享
（3）避免開發(fā)人員犯一些很常見，很普通的錯(cuò)誤
（4）保證項(xiàng)目組人員的良好溝通
（5）項(xiàng)目或產(chǎn)品的代碼更容易維護(hù)
1.2Code Review的前提
進(jìn)入Code Review需要檢查的條件如下：
（1）Code Review人員是否理解了Code Review的概念和Code Review將做什么
如果做Code Review的人員不能理解Code Review對項(xiàng)目成敗和代碼質(zhì)量的重要程度，他們的做法可能就會是應(yīng)付了事。
（2）代碼是否已經(jīng)正確的build，build的目的使得代碼已經(jīng)不存在基本語法錯(cuò)誤
我們總不希望高級開發(fā)人員或是主管將時(shí)間浪費(fèi)在檢查連編譯都通不過的代碼上吧。
（3）代碼執(zhí)行時(shí)功能是否正確
Code Review人員也不負(fù)責(zé)檢查代碼的功能是否正確，也就是說，需要復(fù)查的代碼必須由開發(fā)人員或質(zhì)量人員負(fù)責(zé)該代碼的功能的正確性。
（4）Review人員是否理解了代碼
做復(fù)查的人員需要對該代碼有一個(gè)基本的了解，其功能是什么，是拿一方面的代碼，涉及到數(shù)據(jù)庫或是通訊，這樣才能采取針對性的檢查
（5）開發(fā)人員是否對代碼做了單元測試
這一點(diǎn)也是為了保證Code Review前一些語法和功能問題已經(jīng)得到解決，Code Review人員可以將精力集中在代碼的質(zhì)量上。
1.3 Code Review需要做什么
Code Review主要檢查代碼中是否存在以下方面問題：
代碼的一致性、編碼風(fēng)格、代碼的安全問題、代碼冗余、是否正確設(shè)計(jì)以滿足需求（性能、功能）等等
1.3.1 完整性檢查（Completeness）
代碼是否完全實(shí)現(xiàn)了設(shè)計(jì)文檔中提出的功能需求
代碼是否已按照設(shè)計(jì)文檔進(jìn)行了集成和Debug
代碼是否已創(chuàng)建了需要的數(shù)據(jù)庫，包括正確的初始化數(shù)據(jù)
代碼中是否存在任何沒有定義或沒有引用到的變量、常數(shù)或數(shù)據(jù)類型
1.3.2 一致性檢查（Consistency）
代碼的邏輯是否符合設(shè)計(jì)文檔
代碼中使用的格式、符號、結(jié)構(gòu)等風(fēng)格是否保持一致
1.3.3 正確性檢查（Correctness）
代碼是否符合制定的標(biāo)準(zhǔn)
所有的變量都被正確定義和使用
所有的注釋都是準(zhǔn)確的
所有的程序調(diào)用都使用了正確的參數(shù)個(gè)數(shù)
1.3.4 可修改性檢查（Modifiability）
代碼涉及到的常量是否易于修改(如使用配置、定義為類常量、使用專門的常量類等)
代碼中是否包含了交叉說明或數(shù)據(jù)字典，以描述程序是如何對變量和常量進(jìn)行訪問的
代碼是否只有一個(gè)出口和一個(gè)入口（嚴(yán)重的異常處理除外）
1.3.5 可預(yù)測性檢查（Predictability）
代碼所用的開發(fā)語言是否具有定義良好的語法和語義
是否代碼避免了依賴于開發(fā)語言缺省提供的功能
代碼是否無意中陷入了死循環(huán)
代碼是否是否避免了無窮遞歸
1.3.6 健壯性檢查（Robustness）
代碼是否采取措施避免運(yùn)行時(shí)錯(cuò)誤（如數(shù)組邊界溢出、被零除、值越界、堆棧溢出等）
1.3.7 結(jié)構(gòu)性檢查（Structuredness）
程序的每個(gè)功能是否都作為一個(gè)可辯識的代碼塊存在
循環(huán)是否只有一個(gè)入口
1.3.8 可追溯性檢查（Traceability）
代碼是否對每個(gè)程序進(jìn)行了唯一標(biāo)識
是否有一個(gè)交叉引用的框架可以用來在代碼和開發(fā)文檔之間相互對應(yīng)
代碼是否包括一個(gè)修訂歷史記錄，記錄中對代碼的修改和原因都有記錄
是否所有的安全功能都有標(biāo)識
1.3.9 可理解性檢查（Understandability）
注釋是否足夠清晰的描述每個(gè)子程序
是否使用到不明確或不必要的復(fù)雜代碼，它們是否被清楚的注釋
使用一些統(tǒng)一的格式化技巧（如縮進(jìn)、空白等）用來增強(qiáng)代碼的清晰度
是否在定義命名規(guī)則時(shí)采用了便于記憶，反映類型等方法
每個(gè)變量都定義了合法的取值范圍
代碼中的算法是否符合開發(fā)文檔中描述的數(shù)學(xué)模型
1.3.10可驗(yàn)證性檢查(Verifiability)
代碼中的實(shí)現(xiàn)技術(shù)是否便于測試
1.4 Code Review的步驟
這些是我在平時(shí)工作中的經(jīng)驗(yàn)總結(jié)，目前也是按照這個(gè)步驟在做。
(1)代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UC依次講解自己負(fù)責(zé)的代碼和相關(guān)邏輯，從Web層->DAO層；
(2)代碼審核者在此過程中可以隨時(shí)提出自己的疑問，同時(shí)積極發(fā)現(xiàn)隱藏的bug；對這些bug記錄在案。
(3)代碼講解完畢后，代碼審核者給自己安排幾個(gè)小時(shí)再對代碼審核一遍。
代碼需要一行一行靜下心看。同時(shí)代碼又要全面的看，以確保代碼整體上設(shè)計(jì)優(yōu)良。
(4)代碼審核者根據(jù)審核的結(jié)果編寫“代碼審核報(bào)告”，“審核報(bào)告”中記錄發(fā)現(xiàn)的問題及修改建議，然后把“審核報(bào)告”發(fā)送給相關(guān)人員。
(5)代碼編寫者根據(jù)“代碼審核報(bào)告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。
(6)代碼編寫者 bug fix完畢之后給出反饋。
(7)代碼審核者把Code Review中發(fā)現(xiàn)的有價(jià)值的問題更新到"代碼審核規(guī)范"的文檔中，對于特別值得提醒的問題可群發(fā)email給所有技術(shù)人員。
提示
Code Review必備的文檔：
“代碼審核規(guī)范”文檔：記錄代碼應(yīng)該遵循的標(biāo)準(zhǔn)。
代碼審核者根據(jù)這些標(biāo)準(zhǔn)來Code Review代碼，同時(shí)在Code Review過程中不斷完善該文檔。
2．Code Reivew的執(zhí)行
一個(gè)標(biāo)準(zhǔn)的Code Reivew活動應(yīng)該分為三個(gè)階段：
2.1．事前準(zhǔn)備階段
在一次CR前，對以下內(nèi)容進(jìn)行充分準(zhǔn)備。
2.1.1．CR的對象
在準(zhǔn)備CR代碼對象時(shí)，我們要注意代碼的數(shù)量，如果代碼量比較大，要對代碼進(jìn)行必要的分解，確定其中的關(guān)鍵代碼，對關(guān)鍵代碼進(jìn)行CR，可以達(dá)到舉一反三的目的。
2.1.2．CR的內(nèi)容
我們對代碼的審查內(nèi)容很多，如代碼的編寫是否規(guī)范（注釋的書寫格式、命名規(guī)范等）、技術(shù)處理規(guī)范（異常處理、日志處理、代碼組織結(jié)構(gòu)等）、業(yè)務(wù)實(shí)現(xiàn)等。我們不能希望通過一次CR活動，完成所有這些內(nèi)容的審查，因此我們必須設(shè)定本次CR活動內(nèi)容界限，確定審查重點(diǎn)；
2.1.3．評審規(guī)范和標(biāo)準(zhǔn)
在CR前設(shè)計(jì)確定評審規(guī)范和標(biāo)準(zhǔn)是必要，通過規(guī)范和標(biāo)準(zhǔn)我們在審查過程中可以有據(jù)可依，有理可循，而且還可以做到標(biāo)準(zhǔn)統(tǒng)一。
2.1.4．選擇CR活動的參與者
在CR開始前，必須把本次CR活動的對象、審查內(nèi)容以及審查的規(guī)范和標(biāo)準(zhǔn)通報(bào)給所有的參與者。
2.1.5．選擇CR活動的實(shí)施方式。
CR活動有很多形式可供我們選擇，我們可以根據(jù)實(shí)際情況選擇桌面式CR、演示講解式CR、一對一的座位CR等等。
2.2．實(shí)施階段
充分的事前準(zhǔn)備，只是做好CR活動的前提，在CR實(shí)施過程中，我們要做好以下工作。
2.2.1．準(zhǔn)確記錄
對于CR過程發(fā)現(xiàn)的問題，我們必須清晰準(zhǔn)確的記錄，可以使用問題點(diǎn)記錄單，明確記錄的項(xiàng)目和內(nèi)容。
2.2.2．講解與提問
CR過程中，要采用代碼作者講解和審查者提問方式。審查者不能只在發(fā)現(xiàn)問題時(shí)提問，同時(shí)也要根據(jù)本次審查的內(nèi)容要求代碼作者對某個(gè)特定問題的講解。
2.2.3．逐項(xiàng)審查
對事前確定的審查內(nèi)容，要逐項(xiàng)審查，不能因?yàn)闀r(shí)間不足等因素一掃而過。
2.2.4．注意氣氛
實(shí)施審查時(shí)，要營造一個(gè)討論問題、解決問題的氛圍，不能把審查會搞成批判會，這樣會影響相關(guān)人員的積極性。
2.3. 事后跟蹤跟蹤。
2.3.1. 確認(rèn)發(fā)現(xiàn)的問題
CR結(jié)束后，對發(fā)現(xiàn)的問題，首先需要確定以下內(nèi)容。
1．問題點(diǎn)的難易程度以及影響的范圍；
2．解決問題的責(zé)任者和問題點(diǎn)修正結(jié)果的確認(rèn)者；
3．解決問題點(diǎn)的時(shí)限。
2.32. 修正問題責(zé)任者
對于修正問題責(zé)任者，在問題點(diǎn)的修正過程中，要三方面內(nèi)容的記錄。
1．問題點(diǎn)的原因；
2．解決問題點(diǎn)的對策；
3．修正的內(nèi)容。
2.3.3. 修正結(jié)果確認(rèn)者
做為修正結(jié)果的確認(rèn)者，必須按照事前約定的時(shí)限及時(shí)的對修正結(jié)果進(jìn)行全面的確認(rèn)
3．注意事項(xiàng)
3.1. 經(jīng)常進(jìn)行Code Review
（1）要Review的代碼越多，那么要重構(gòu)，重寫的代碼就會越多。而越不被程序作者接受的建議也會越多，唾沫口水戰(zhàn)也會越多。
（2）程序員代碼寫得時(shí)候越長，程序員就會在代碼中加入越來越多的個(gè)人的東西。
（3）越接近軟件發(fā)布的最終期限，代碼也就不能改得太多。
3.2. Code Review不要太正式，而且要短
忘了那個(gè)代碼評審的Checklist吧，走到你的同事座位跟前，像請師父一樣請他坐到你的電腦面前，然后，花5分鐘給他講講你的代碼，給他另外一個(gè)5分鐘讓他給你的代碼提提意見，這比什么都好。而如果你用了一個(gè)Checklist，讓這個(gè)事情表現(xiàn)得很正式的話，下面兩件事中必有一件事會發(fā)生：
（1）只有在Checklist上存在的東西才會被Review。
（2）Code Reviews 變成了一種禮節(jié)性的東西，你的同事會裝做很關(guān)心你的代碼，但其實(shí)他心里想著盡快地離開你。
只有不正式的Code Review才會讓你和評審者放輕松，人只有放松了，才會表現(xiàn)得很真實(shí)，很真誠。記住Review只不過是一種形式，而只有在相互信任中通過相互的討論得到了有意義和有建設(shè)性的建議和意見，那才是最實(shí)在的。不然，作者和評審者的關(guān)系就會變成小偷和警察的關(guān)系。
3.3. 盡可能的讓不同的人Reivew你的代碼
如果可能的話，不要總是只找一個(gè)人來Review你的代碼，不同的人有不同的思考方式，有不同的見解，所以，不同的人可以全面的從各個(gè)方面評論你的代碼。
但不要太多了，人多嘴雜反而適得其反，基本上來說，不要超過3個(gè)人，這是因?yàn)?，這是一個(gè)可以圍在一起討論的***人員尺寸。
下面是幾個(gè)優(yōu)點(diǎn)：
（1）從不同的方向評審代碼總是好的。
（2）會有更多的人幫你在日后維護(hù)你的代碼。
（3）這也是一個(gè)增加團(tuán)隊(duì)凝聚力的方法。
3.4. 保持積極的正面的態(tài)度
程序員***的問題就是“自負(fù)”，尤其當(dāng)我們Reivew別人的代碼的時(shí)候，我已經(jīng)見過無數(shù)的場面，程序員在Code Review的時(shí)候，開始抨擊別人的代碼，質(zhì)疑別人的能力。太可笑了，我分析了一下，這類的程序員其實(shí)并沒有什么本事，因?yàn)樗麄冎肛?zé)對方的目的是想告訴大家自己有多么的牛，靠這種手段來表現(xiàn)自己的程序員，其實(shí)是就是傳說中所說的“半瓶水”。
所以，無論是代碼作者，還是評審者，都需要一種積極向上的正面的態(tài)度，作者需要能夠虛心接受別人的建議，因?yàn)閯e人的建議是為了讓你做得更好；評審者也需要以一種積極的正面的態(tài)度向作者提意見，因?yàn)槟鞘呛湍阍谝粋€(gè)戰(zhàn)壕里的戰(zhàn)友。記住，你不是一段代碼，你是一個(gè)人！
3.5. 學(xué)會享受Code Reivew
這可能是最重要的一個(gè)提示了，如果你到了一個(gè)人人都喜歡Code Reivew的團(tuán)阿，那么，你會進(jìn)入到一個(gè)生機(jī)勃勃的地方，在那里，每個(gè)人都能寫出質(zhì)量非常好的代碼，在那里，你不需要經(jīng)理的管理，團(tuán)隊(duì)會自適應(yīng)一切變化，他們相互學(xué)習(xí)，相互幫助，不僅僅是寫出好的代碼，而且團(tuán)隊(duì)和其中的每個(gè)人都會自動進(jìn)化，最關(guān)鍵的是，這個(gè)是一個(gè)團(tuán)隊(duì)。
原文鏈接：http://www.cnblogs.com/IT-Bear/archive/2012/07/04/2576367.html
名稱欄目：CodeReview代碼審查的思路
標(biāo)題URL：http://fisionsoft.com.cn/article/cdeippi.html
