[[143001]]

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

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

代碼審查的好處

我們發(fā)現(xiàn)代碼審查對于項目的各個階段都會帶來很多好處：

• 在項目起始階段進行代碼審查會幫助我們更好地使用已經(jīng)建立起來的代碼基，因為如果我們沒有使用過某些現(xiàn)有代碼，那么可以從當前的開發(fā)者中獲得反饋信息。
• 在項目進行過程中，我們會時不時地向團隊增加新的開發(fā)人員，代碼審查可以極大地降低這些新加入人員的熟悉時間。特別地，我們可以讓新加入的開發(fā)人員很有信心地開發(fā)新特性，因為我們可以在合并前審查代碼并且對于他們所編寫的任何代碼提供有價值的反饋信息。
• 對于我們這個分布式團隊來說，代碼審查更加具有實際意義。團隊協(xié)同在構(gòu)建協(xié)作環(huán)境上會帶來很大的幫助作用，我們可以即時提出想法，然后討論，再進行開發(fā)。雖然由于不在同一地點我們會失去一些東西，不過我們卻可以在代碼審查過程中通過深入的討論來獲得好處。

高效代碼審查的技巧

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

使用特性分支

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

將審查隔離為小的修改

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

使用專門為代碼審查而設計的工具

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

檢查清單

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

有建設性的輸入

類似于“多加點注釋”這樣的話顯得太沒意義了，幫助也不大。假如某個接口沒有注釋，但也許有專門的文檔用來說明呢。如果發(fā)現(xiàn)了某些不合理的地方，那就要明確指出來，判斷設計上是否能改進或是邏輯上是否存在著錯誤。

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

人人參與

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

要有審查流程

一開始，我們的項目并沒有正規(guī)的審查流程。我們只是開啟一個pull request，等待有人來審查，***會有人合并修改。這種工作方式效率非常差，有時好幾天都沒人審查一個pull request，有時一個人給出反饋前其他人卻合并了請求。此外，有些開發(fā)者審查的代碼量要比其他人多不少。總而言之，沒有流程導致我們的效率極低。

***我們認識到了這一點，創(chuàng)建了一個正式的結(jié)構(gòu)來指導該如何進行代碼審查，這加速了審查的效率。一個審查過程至少應該涵蓋如下幾點：

• 如何將審查任務分派給不同的人
• 期待審查者給出反饋的最遲時間
• 如何標識某個審查已經(jīng)完成
• 誰負責合并已經(jīng)完成審查的代碼

我在項目中是否應該進行代碼審查？

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

• 至少有5名開發(fā)人員
• 在向團隊增加新的開發(fā)人員時
• 團隊是分布式的
• 項目有各種不同的組件構(gòu)成，這些組件是由不同團隊開發(fā)的
• 當還處在為代碼基設定約定以及***實踐的階段
• 團隊中有些成員對于當前所使用的技術棧還不太熟悉時

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

• 處理的是維護代碼而不是添加新的特性
• 團隊很小且親密無間