高效代碼審查的十個(gè)經(jīng)驗

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

　　1. 代碼審查要求團隊有良好的文化

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

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

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

　　2. 謹慎的使用審查中問(wèn)題的發(fā)現率作為考評標準

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

　　3. 控制每次審查的代碼數量

　　根據smartbear在思科所作的調查，每次審查200行-400行的代碼效果最好。每次試圖審查的代碼過(guò)多，發(fā)現問(wèn)題的能力就會(huì )下降，具體的比例關(guān)系如下圖所示：

　　我們在實(shí)踐中發(fā)現，隨著(zhù)開(kāi)發(fā)平臺和開(kāi)發(fā)語(yǔ)言的不同，最優(yōu)的代碼審查量有所不同。但是限制每次審查的數量確實(shí)非常必要，因為這個(gè)過(guò)程是高強度的腦力密集型活動(dòng)。時(shí)間一長(cháng)，代碼在審查者眼里只是字母，無(wú)任何邏輯聯(lián)系，自然不會(huì )有太多的產(chǎn)出。

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

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

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

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

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

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

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

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

　　(2) 讓原作者了解問(wèn)題和不足，幫助其成長(cháng)。

　　有些時(shí)候為了追求效率，有經(jīng)驗的審查者更傾向于直接修改代碼乃至重構所有代碼，但這樣不利于提高團隊效率，并且會(huì )增加因為重構引入新bug的幾率，通常情況下我們不予鼓勵。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文轉自：http://kjueaiud.com/deltestingadmindd/