分享高效代碼審查的十個(gè)經(jīng)驗(yàn)

代碼審查(Code Review)是軟件開發(fā)中常用的手段，和QA測試相比，它更容易發(fā)現(xiàn)和架構(gòu)以及時(shí)序相關(guān)等較難發(fā)現(xiàn)的問題，還可以幫助團(tuán)隊(duì)成員提高編程技能，統(tǒng)一編程風(fēng)格等。

1. 代碼審查要求團(tuán)隊(duì)有良好的文化

團(tuán)隊(duì)需要認(rèn)識(shí)到代碼審查是為了提高整個(gè)團(tuán)隊(duì)的能力，而不是針對個(gè)體設(shè)置的檢查“關(guān)卡”。

“A的代碼有個(gè)bug被B發(fā)現(xiàn)，所以A能力不行，B能力更好”，這一類的陷阱很容易被擴(kuò)散從而影響團(tuán)隊(duì)內(nèi)部的協(xié)作，因此需要避免。

另外，代碼審查本身可以提高開發(fā)者的能力，讓其從自身犯過的錯(cuò)誤中學(xué)習(xí)，從他人的思路中學(xué)習(xí)。如果開發(fā)者對這個(gè)流程有抵觸或者反感，這個(gè)目的就達(dá)不到。

2. 謹(jǐn)慎的使用審查中問題的發(fā)現(xiàn)率作為考評標(biāo)準(zhǔn)

在代碼審查中如果發(fā)現(xiàn)問題，對于問題的發(fā)現(xiàn)者來說這是好事，應(yīng)該予以鼓勵(lì)。但對于被發(fā)現(xiàn)者，我們不主張使用這個(gè)方式予以懲罰。軟件開發(fā)中bug在所難免，過度苛求本身有悖常理。更糟的是，如果造成參與者怕承擔(dān)責(zé)任，不愿意在審查中指出問題，代碼審查就沒有任何的價(jià)值和意義。

3. 控制每次審查的代碼數(shù)量

根據(jù)smartbear在思科所作的調(diào)查，每次審查200行-400行的代碼效果最好。每次試圖審查的代碼過多，發(fā)現(xiàn)問題的能力就會(huì)下降，我們在實(shí)踐中發(fā)現(xiàn)，隨著開發(fā)平臺(tái)和開發(fā)語言的不同，最優(yōu)的代碼審查量有所不同。但是限制每次審查的數(shù)量確實(shí)非常必要，因?yàn)檫@個(gè)過程是高強(qiáng)度的腦力密集型活動(dòng)。時(shí)間一長，代碼在審查者眼里只是字母，無任何邏輯聯(lián)系，自然不會(huì)有太多的產(chǎn)出。

4. 帶著問題去進(jìn)行審查

我們在每次代碼審查中，要求審查者利用自身的經(jīng)驗(yàn)先思考可能會(huì)碰到的問題，然后通過審查工作驗(yàn)證這些問題是否已經(jīng)解決。一個(gè)竅門是，從用戶可見的功能出發(fā)，假設(shè)一個(gè)比較復(fù)雜的使用場景，在代碼閱讀中驗(yàn)證這個(gè)使用場景是否能夠正確工作。

使用這個(gè)技巧，可以讓審查者有代入感，真正的沉浸入代碼中，提高效率。大家都知道看武俠小說不容易瞌睡，而看專業(yè)書容易瞌睡，原因就是武俠小說更容易產(chǎn)生代入感。

有的研究建議每次樹立目標(biāo)，控制單位時(shí)間內(nèi)審核的代碼數(shù)量。這個(gè)方法在我們的實(shí)踐中顯得很機(jī)械和流程化，不如上面的方法效果好。

5. 所有的問題和修改，必須由原作者進(jìn)行確認(rèn)

如果在審查中發(fā)現(xiàn)問題，務(wù)必由原作者進(jìn)行確認(rèn)。

這樣做有兩個(gè)目的：

(1)確認(rèn)問題確實(shí)存在，保證問題被解決

(2)讓原作者了解問題和不足，幫助其成長

有些時(shí)候?yàn)榱俗非笮?，有?jīng)驗(yàn)的審查者更傾向于直接修改代碼乃至重構(gòu)所有代碼，但這樣不利于提高團(tuán)隊(duì)效率，并且會(huì)增加因?yàn)橹貥?gòu)引入新bug的幾率，通常情況下我們不予鼓勵(lì)。

6.利用代碼審查激活個(gè)體“能動(dòng)性"

即使項(xiàng)目進(jìn)度比較緊張，無法完全的進(jìn)行代碼審查，至少也要進(jìn)行部分代碼的審查，此時(shí)隨即抽取一些關(guān)鍵部分是個(gè)不錯(cuò)的辦法。

背后的邏輯是，軟件開發(fā)是非常有創(chuàng)造性的工作，開發(fā)者都有強(qiáng)烈的自我驅(qū)動(dòng)性和自我實(shí)現(xiàn)的要求。讓開發(fā)者知道他寫的任何代碼都可能被其他人閱讀和審察，可以促使開發(fā)者集中注意力，尤其是避免將質(zhì)量糟糕，乃至有低級錯(cuò)誤的代碼提交給同伴審查。開源軟件也很好的利用了這種心態(tài)來提高代碼質(zhì)量。

7.在非正式，輕松的環(huán)境下進(jìn)行代碼審查

如前所述，代碼審查是一個(gè)腦力密集型的工作。參與者需要在比較輕松的環(huán)境下進(jìn)行該工作。因此，我們認(rèn)為像某些實(shí)踐中建議的那樣，以會(huì)議的形式進(jìn)行代碼審查效果并不好，不僅因?yàn)殚L時(shí)間的會(huì)議容易讓效率低下，更因?yàn)闀?huì)議上可能出現(xiàn)的爭議和思考不利于進(jìn)行如此復(fù)雜的工作。

8.提交代碼前自我審查，添加對代碼的說明

所有團(tuán)隊(duì)成員在提交代碼給其他成員審查前，必須先進(jìn)行一次審查。這次自我修正形式的審查除了檢查代碼的正確性以外，還可以完成如下的工作：

(1)對代碼添加注釋，說明本次修改背后的原因，方便其他人進(jìn)行審查。

(2)修正編碼風(fēng)格，尤其是一些關(guān)鍵數(shù)據(jù)結(jié)構(gòu)和方法的命名，提高代碼的可讀性。

(3)從全局審視設(shè)計(jì)，是否完整的考慮了所有情景。在實(shí)現(xiàn)之前做的設(shè)計(jì)如果存在考慮不周的情況，這個(gè)階段可以很好的進(jìn)行補(bǔ)救。

我們在實(shí)踐中發(fā)現(xiàn)，即使只有原作者進(jìn)行代碼審查，仍然可以很好的提高代碼質(zhì)量。

9.實(shí)現(xiàn)中記錄筆記可以很好的提高問題發(fā)現(xiàn)率

成員在編碼的時(shí)候應(yīng)做隨手記錄，包括在代碼中用注釋的方式表示，或者記錄簡單的個(gè)人文檔，這樣做有幾個(gè)好處：

(1)避免遺漏。在編碼時(shí)將考慮到的任何問題都記錄下來，在審查階段再次檢查這些問題都確認(rèn)解決。

(2)根據(jù)研究，每個(gè)人都習(xí)慣犯一些重復(fù)性的錯(cuò)誤。這類問題在編碼是記錄下來，可以在審查的時(shí)候用作檢查的依據(jù)。

(3)在反復(fù)記錄筆記并在審查中發(fā)現(xiàn)類似的問題后，該類問題出現(xiàn)率會(huì)顯著下降

10. 使用好的工具進(jìn)行輕量級的代碼審查

“工欲善其事，必先利其器”。我們使用的是bitbucket提供的代碼托管服務(wù)。

每個(gè)團(tuán)隊(duì)成員獨(dú)立開發(fā)功能，然后利用Pull Request的形式將代碼提交給審查者。復(fù)審者可以很方便在網(wǎng)頁上閱讀代碼，添加評論等，然后原作者會(huì)自動(dòng)收到郵件提醒，對審閱的意見進(jìn)行討論。

即使團(tuán)隊(duì)成員分布在天南海北，利用bitbucket提供的工具也能很好的進(jìn)行代碼審查。

網(wǎng)頁名稱：分享高效代碼審查的十個(gè)經(jīng)驗(yàn)
URL地址：http://www.muchs.cn/news30/319380.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供云服務(wù)器、網(wǎng)站建設(shè)、微信公眾號(hào)、搜索引擎優(yōu)化、定制開發(fā)、

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)