Jim Bird是一位經驗豐富的軟件開發經理、項目經理與CTO，專注於軟件開發與維護、軟件質量與安全等領域中疑難問題的解決。在過去的15年間，Jim曾管理過團隊建設並主導過高性能的財務系統的建設。他的主要興趣在於如何提升小團隊的效率以構建真正的軟件：高質量、安全、可靠、高性能及適應性強。近日，Jim撰寫了一篇博文，談到了代碼審查的價值，如何進行代碼審查，代碼審查的過程以及在代碼審查中需要注意的問題，希望能爲大家平日的代碼審查帶來一些啓示。
開始代碼審查
從一開始，開發者就會互相幫助，如果測試中遇到了問題或是有新人加入到了團隊，領導或是資深開發者就會審查他們的代碼。除此之外，我們還聘請了外部專家進行安全代碼審查。
系統發佈後，我們決定更加主動一些，開始了基於風險的審查：項目中有人會編寫一些風險較高的代碼（比如說框架與安全代碼、APIs、核心業務邏輯或是之前曾經出現過問題的地方），我們會審查他們的代碼。在這個過程中，代碼審查體現出了它的價值，我們收穫頗豐。即便如此，我們還是更進一步，讓代碼審查成爲一個標準的實踐。
這並不是一夜之間就形成的。讓團隊相信代碼審查的價值並不是什麼難事，他們已經通過基於風險的審查獲得了收益。不過要想改變人們的工作方式就不是那麼簡單的事情了，還要確保他們有足夠的時間進行代碼審查，理解並對反饋作出響應。此外，設計一個高效的代碼審查流程也是需要花時間的。
一開始，我們讓開發者選擇好搭檔並安排審查，但結果卻有些混亂。有時，開發者會尋找那些好說話或是比較忙的人，這樣審查就比較容易通過了；此外，兩個開發者還有可能事先商量好，因此審查過程就會很快結束。由於人們並不知道要花費多少時間才能完成代碼審查，因此審查經常會拖得很久，常常在代碼已經完成測試甚至是發佈後才完成。
由於大多數人並沒有太多的代碼審查經驗，因此他們並不確定在審查時應該看什麼，如何給出有意義的反饋等信息。開發者常常會被負面的批評搞得很沮喪，有時甚至會心煩意亂。
最後，我們決定由領導來完成大部分審查工作。雖然這會增加領導的工作量，也意味着他們沒有太多時間編寫代碼了，不過這麼做卻是很有效果的。通常情況下，主開發者會對需求有着更好的理解，對代碼的行爲有着清晰的認識，這也意味着他們更有可能發現代碼中的錯誤。由於是同一個人完成了大部分的代碼審查，因此被審查的開發者會收到一致的反饋信息。
我們如何進行代碼審查
在過去的幾年間，我們進行代碼審查的方式幾乎沒有發生過什麼大的變化。
無論是誰編寫的，無論代碼的功能是什麼，重要的代碼變更是一定要審查的。我們並沒有一個正式的審查會議，也沒發現使用諸如Code Collaborator、Crucible等工具有什麼必要性，不過現在看起來使用這些工具來管理和追蹤審查有助於團隊更好的起步。
有時，審查是面對面完成的，不過大多數時候都是離線進行的。審查者與開發者會交換信息，也許通過郵件發送文件，因爲我們覺得這種方式更加便捷，也更加方便每一個人安排自己的時間。
隨着時間的流逝，審查中的變化之處是審查者該看什麼，以及看到的結果。
審查正確性
很多時候，程序員們會花費很多時間爭論在代碼審查過程中應該看什麼，但實際上他們卻沒有花太多時間完成真正的代碼審查。
我們開始代碼審查的目的是改進代碼質量，尋找測試中沒有發現的問題。這麼做並不是教授經驗不足的開發者如何編寫更好的代碼，或是如何在團隊內分享知識。這些都應該是代碼審查所帶來的間接好處，不過審查的最終目的應該是確保代碼能夠正常工作。
相對於使用長長的檢查列表，審查者在看代碼時首先會問幾個問題：
- 代碼的行爲是否與預期一致，其邏輯是否是正確無誤的？
- 被審查的代碼是否與其他代碼擁有類似的結構和功能？
審查可理解性
隨着時間的流逝，在代碼審查中尋找和得到的東西會發生變化。這是因爲代碼本身會發生變化，完成這項工作的人——開發者與審查者也可能發生變化。
開發者需要在其IDE中裝上代碼檢查工具，同時我們也要使用一些優秀的靜態分析工具來自動檢查常見的編碼Bug和不好的編碼實踐。這意味着審查者的時間可以花在更加重要的設計錯誤上，比如說併發Bug、競態條件和潛在的死鎖等，因爲這些問題是工具所無法檢測到的。
理解，而不是批評
審查的目的是理解代碼，確保代碼能夠正常工作，而不是批評任何人。
在代碼審查過程中，請不要摻入諸如“我認爲好的代碼是什麼，你認爲好的代碼是什麼”這樣的論戰之中。代碼審查應該重點關注“我需要完全理解這部分代碼才能確保它能夠正常工作，如果由我來修復代碼中的問題，我是不會這麼寫的，因此希望你也不要這麼來寫”。
隨着時間的流逝，有些東西會變好，有些則不然
隨着時間的流逝，在查看代碼時你會發現代碼在不斷變化。Michael Feathers發現大部分代碼在寫完後很少或是從來都不會變化；大部分變更都是發生在代碼基中的很小一部分代碼上的。
由於審查者會看到相同的代碼在不斷髮生着變化，因此這也會改變他們的審查方式。
避免收益遞減
類似於軟件開發中的其他實踐一樣，你最終會發現代碼審查有着收益遞減的效應，特別是一直在做相同的事情的時候，以相同的方式查看相同的問題。最終會有這樣一個階段，那就是代碼審查的價值幾乎降到了0。不過這種情況並沒有發生在我們身上，我們依然從代碼審查過程中獲得了很多收益。
即便改進了工具，增強了測試能力，我們依然進行代碼審查，因爲Bug檢查工具、審查與測試會發現不同類型的問題。我們還發現代碼審查會讓測試更加高效，這是因爲如果之前曾經發現過問題，那麼開發者與測試者之間就不會出現過多的往復情況。