代碼審查的價(jià)值——為何做、何時(shí)做、如何做?

　　對于很多公司來(lái)說(shuō)，代碼審查是開(kāi)發(fā)人員日常工作中的重要環(huán)節。通過(guò)代碼審查，可以及早發(fā)現項目中存在的問(wèn)題、促進(jìn)同事之間的溝通與交流，并且可以在討論中迸發(fā)出智慧的火花。但要想成功實(shí)施代碼審查卻并不是一件輕松的事情，為什么要進(jìn)行代碼審查、何時(shí)做、如何做，這是擺在我們面前的3個(gè)重要問(wèn)題。針對于這3個(gè)問(wèn)題，開(kāi)發(fā)者Lisa Tjapkes撰文談到了自己的經(jīng)驗與教訓。

　　在我最近的項目經(jīng)歷中，我們進(jìn)行了廣泛且正式的代碼審查。這個(gè)過(guò)程極大地改進(jìn)了項目的代碼質(zhì)量，降低了項目中新特性開(kāi)發(fā)的等待時(shí)間，同時(shí)還促進(jìn)了知識在整個(gè) 團隊間的傳播與共享。我還發(fā)現代碼審查并不會(huì )延誤項目開(kāi)發(fā)的時(shí)間，反而會(huì )提升開(kāi)發(fā)人員的生產(chǎn)力。代碼審查的好處

　　我們發(fā)現代碼審查對于項目的各個(gè)階段都會(huì )帶來(lái)很多好處：

　　在項目起始階段進(jìn)行代碼審查會(huì )幫助我們更好地使用已經(jīng)建立起來(lái)的代碼基，因為如果我們沒(méi)有使用過(guò)某些現有代碼，那么可以從當前的開(kāi)發(fā)者中獲得反饋信息。

　　在項目進(jìn)行過(guò)程中，我們會(huì )時(shí)不時(shí)地向團隊增加新的開(kāi)發(fā)人員，代碼審查可以極大地降低這些新加入的人員的熟悉時(shí)間。特別地，我們可以讓新加入的開(kāi)發(fā)人員很有信心地開(kāi)發(fā)新特性，因為我們可以在合并前審查代碼并且對于他們所編寫(xiě)的任何代碼提供有價(jià)值的反饋信息。

　　對于我們這個(gè)分布式團隊來(lái)說(shuō)，代碼審查更加具有實(shí)際意義。團隊協(xié)同在構建協(xié)作環(huán)境上會(huì )帶來(lái)很大的幫助作用，我們可以即時(shí)提出想法、然后討論，再進(jìn)行開(kāi)發(fā)。雖然由于不在同一地點(diǎn)我們會(huì )失去一些東西，不過(guò)我們卻可以在代碼審查過(guò)程中通過(guò)深入的討論來(lái)獲得好處。

　　高效代碼審查的技巧

　　代碼審查的方式如果處理不當可能會(huì )導致項目延期。使用正確的工具與技術(shù)可以防止在審查上浪費大量的時(shí)間，提升代碼的品質(zhì)。

　　使用特性分支

　　這個(gè)實(shí)踐的好處就不用多說(shuō)了，不過(guò)它對代碼審查提供了更加具體的好處。特性分支意味著(zhù)你可以將需要審查的代碼隔離到只與某個(gè)具體的特性相關(guān)。在代碼已經(jīng)準備好了審查時(shí)，特性分支還考慮到了快速的上下文切換。在當前的代碼進(jìn)行審查時(shí)，你可以切換到新的特性上來(lái)，如果需要對審查特性的反饋進(jìn)行討論時(shí)還可以快速切換回來(lái)。

　　將審查隔離為小的修改

　　相對于大的修改來(lái)說(shuō)，小修改的審查時(shí)間會(huì )更少。在審查大的修改時(shí)，你不僅要看很多行代碼，還要查看大量的依賴(lài)代碼才能真正理解，結果就是花在審查代碼上的時(shí)間與修改的代碼量之間并不是呈線(xiàn)性關(guān)系。將待審查的代碼隔離為小的修改可以降低審查者的精神負擔并讓審查過(guò)程更加順暢。

　　使用專(zhuān)門(mén)為代碼審查而設計的工具

　　這看起來(lái)似乎很簡(jiǎn)單，但卻非常重要。一些重要的特性需要包含差異比較、能夠逐行注釋修改，并且在審查的代碼發(fā)生改變時(shí)通知大家。我所在的團隊使用GitHub來(lái)管理項目代碼，并且使用GitHub的pull request特性來(lái)管理代碼審查。

　　檢查清單

　　可能沒(méi)必要使用非常復雜或是過(guò)于結構化的東西，如果突然出現了某些問(wèn)題，使用檢查清單或許是個(gè)不錯的主意。

　　有建設性的輸入

　　類(lèi)似于“多加點(diǎn)注釋”這樣的話(huà)顯得太沒(méi)意義了，幫助也不大。假如某個(gè)接口沒(méi)有注釋?zhuān)苍S有專(zhuān)門(mén)的文檔用來(lái)說(shuō)明呢。如果發(fā)現了某些不合理的地方，那就要明確指出來(lái)，判斷設計上是否能改進(jìn)或是邏輯上是否存在著(zhù)錯誤。

　　要把精力放在真正理解代碼的行為上，確保當其他人需要維護它時(shí)也能夠快速理解代碼。

　　人人參與

　　即便是最有經(jīng)驗的架構師或是明星開(kāi)發(fā)者也會(huì )犯錯。因此，最好每個(gè)人都能參與到代碼審查的過(guò)程中來(lái)。特別地，對于很多初級開(kāi)發(fā)者或是新加入項目的開(kāi)發(fā)者來(lái)說(shuō)，這也是個(gè)很不錯的學(xué)習機會(huì )。

　　要有審查流程

　　一開(kāi)始，我們的項目并沒(méi)有正規的審查流程。我們只是開(kāi)啟一個(gè)pull request，等待有人來(lái)審查，最后會(huì )有人合并修改。這種工作方式效率非常差，有時(shí)好幾天都沒(méi)人審查一個(gè)pull request，有時(shí)一個(gè)人給出反饋前其他人卻合并了請求。此外，有些開(kāi)發(fā)者審查的代碼量要比其他人多不少?？偠灾?，沒(méi)有流程導致我們的效率極低。

　　最后我們認識到了這一點(diǎn)，創(chuàng )建了一個(gè)正式的結構來(lái)指導該如何進(jìn)行代碼審查，這加速了審查的效率。一個(gè)審查過(guò)程至少應該涵蓋如下幾點(diǎn)：

　　如何將審查任務(wù)分派給不同的人

　　期待審查者給出反饋的最遲時(shí)間

　　如何標識某個(gè)審查已經(jīng)完成

　　誰(shuí)負責合并已經(jīng)完成審查的代碼

　　我在項目中是否應該進(jìn)行代碼審查?

　　我認為代碼審查對于很多項目來(lái)說(shuō)都是一件好事，不過(guò)它也并非通用的解決方案。代碼審查適合于如下這些項目：

　　至少有5名開(kāi)發(fā)人員

　　在向團隊增加新的開(kāi)發(fā)人員時(shí)

　　團隊是分布式的

　　項目有各種不同的組件構成，這些組件是由不同團隊開(kāi)發(fā)的

　　當還處在為代碼基設定約定以及最佳實(shí)踐的階段

　　團隊中有些成員對于當前所使用的技術(shù)棧還不太熟悉時(shí)

　　相反，代碼審查在如下的情形中并不會(huì )為項目帶來(lái)更多的附加值：

　　處理的是維護代碼而不是添加新的特性

　　團隊很小且親密無(wú)間

　　各位InfoQ讀者們，你在工作中使用過(guò)代碼審查么，你們的團隊是如何做的呢，實(shí)踐過(guò)程當中有哪些值得堅持的做法，又有哪些不太好的做法呢?歡迎大家一起討論。

原文轉自：http://www.kuqin.com/shuoit/20131110/336179.html