高效程式碼審查的十個經驗

　　程式碼審查（Code Review)是軟體開發中常用的手段，和QA測試相比，它更容易發現和架構以及時序相關等較難發現的問題，還可以幫助團隊成員提高程式設計技能，統一程式設計風格等。

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

　　團隊需要認識到程式碼審查是為了提高整個團隊的能力，而不是針對個體設定的檢查“關卡”。

　　“A的程式碼有個bug被B發現，所以A能力不行，B能力更好”，這一類的陷阱很容易被擴散從而影響團隊內部的協作，因此需要避免。

　　另外，程式碼審查本身可以提高開發者的能力，讓其從自身犯過的錯誤中學習，從他人的思路中學習。如果開發者對這個流程有牴觸或者反感，這個目的就達不到。

　　2. 謹慎的使用審查中問題的發現率作為考評標準

　　在程式碼審查中如果發現問題，對於問題的發現者來說這是好事，應該予以鼓勵。但對於被發現者，我們不主張使用這個方式予以懲罰。軟體開發中bug在所難免，過度苛求本身有悖常理。更糟的是，如果造成參與者怕承擔責任，不願意在審查中指出問題，程式碼審查就沒有任何的價值和意義。

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

　　根據smartbear在思科所作的調查，每次審查200行-400行的程式碼效果最好。每次試圖審查的程式碼過多，發現問題的能力就會下降，具體的比例關係如下圖所示：

　　我們在實踐中發現，隨著開發平臺和開發語言的不同，最優的程式碼審查量有所不同。但是限制每次審查的數量確實非常必要，因為這個過程是高強度的腦力密集型活動。時間一長，程式碼在審查者眼裡只是字母，無任何邏輯聯絡，自然不會有太多的產出。

　　4. 帶著問題去進行審查

　　我們在每次程式碼審查中，要求審查者利用自身的經驗先思考可能會碰到的問題，然後通過審查工作驗證這些問題是否已經解決。一個竅門是，從使用者可見的功能出發，假設一個比較複雜的使用場景，在程式碼閱讀中驗證這個使用場景是否能夠正確工作。

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

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

　　5. 所有的問題和修改，必須由原作者進行確認

　　如果在審查中發現問題，務必由原作者進行確認。

　　這樣做有兩個目的：

　　(1)確認問題確實存在，保證問題被解決

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

　　有些時候為了追求效率，有經驗的審查者更傾向於直接修改程式碼乃至重構所有程式碼，但這樣不利於提高團隊效率，並且會增加因為重構引入新bug的機率，通常情況下我們不予鼓勵。

　　6.利用程式碼審查啟用個體“能動性"

　　即使專案進度比較緊張，無法完全的進行程式碼審查，至少也要進行部分程式碼的審查，此時隨即抽取一些關鍵部分是個不錯的辦法。

　　背後的邏輯是，軟體開發是非常有創造性的工作，開發者都有強烈的自我驅動性和自我實現的要求。讓開發者知道他寫的任何程式碼都可能被其他人閱讀和審察，可以促使開發者集中注意力，尤其是避免將質量糟糕，乃至有低階錯誤的程式碼提交給同伴審查。開源軟體也很好的利用了這種心態來提高程式碼質量。

　　7.在非正式，輕鬆的環境下進行程式碼審查

　　如前所述，程式碼審查是一個腦力密集型的工作。參與者需要在比較輕鬆的環境下進行該工作。因此，我們認為像某些實踐中建議的那樣，以會議的形式進行程式碼審查效果並不好，不僅因為長時間的會議容易讓效率低下，更因為會議上可能出現的爭議和思考不利於進行如此複雜的工作。

　　8.提交程式碼前自我審查，新增對程式碼的說明

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

　　(1)對程式碼新增註釋，說明本次修改背後的原因，方便其他人進行審查。

　　(2)修正編碼風格，尤其是一些關鍵資料結構和方法的命名，提高程式碼的可讀性。

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

　　我們在實踐中發現，即使只有原作者進行程式碼審查，仍然可以很好的提高程式碼質量。

　　9.實現中記錄筆記可以很好的提高問題發現率

　　成員在編碼的時候應做隨手記錄，包括在程式碼中用註釋的方式表示，或者記錄簡單的個人文件，這樣做有幾個好處：

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

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

　　(3)在反覆記錄筆記並在審查中發現類似的問題後，該類問題出現率會顯著下降

　　10. 使用好的工具進行輕量級的程式碼審查

　　“工欲善其事，必先利其器”。我們使用的是bitbucket提供的程式碼託管服務。

　　每個團隊成員獨立開發功能，然後利用Pull Request的形式將程式碼提交給審查者。複審者可以很方便在網頁上閱讀程式碼，新增評論等，然後原作者會自動收到郵件提醒，對審閱的意見進行討論。

　　即使團隊成員分佈在天南海北，利用bitbucket提供的工具也能很好的進行程式碼審查。