本文翻譯自：https://dzone.com/articles/4-types-of-code-reviews-any-professional-developer
轉載請註明出處：葡萄城官網，葡萄城為開發者提供專業的開發工具、解決方案和服務，賦能開發者。
沒有人能保證他產出的程式碼一定是完美的。下文闡述了4種主流的程式碼審查(code review)型別，相信作為專業的開發人員，你應該都瞭解它們！
每個專業的軟體開發者都知道，程式碼審查是任何正式開發過程中的必要環節。但大多數開發者不知道的是，程式碼審查分為很多種型別。根據你專案和團隊架構的不同，每一種程式碼審查型別都有它特有的優缺點。
我將在本文列出幾種程式碼的審查的型別，並詳細解釋它們各自是如何工作的。並且，我也將對你在何時做出哪種選擇給出一些建議。
好了，讓我們開始吧。
首先，在一個很高的層面，你可以將程式碼審查歸為兩大類：正式的程式碼審查(formal code review)，和輕量級的程式碼審查(light weight code review)。
正式的程式碼審查
正式的程式碼審查是基於正式的開發流程。其中最流行的實踐是範根檢查法(Fagan inspection)。
它為試圖尋找程式碼的缺陷提供了一種非常結構化的流程，並且，它還可以用於發現規範(specifications)中的或者設計中的缺陷。
範根檢查法由6個步驟組成：計劃(Planning)，概述(Overview)，準備(Preparation)，召開檢查會議(Inspection Meeting)，重做(Rework)，和追查(Follow-up)。基本的思想是：預先制定好每一個步驟所需要達到的輸出要求。接下來，當進行到某個過程時，你檢查其現在的輸出，並與之前制定的理想輸出要求做比較。然後，你由此來決定，是否進入下一個步驟，或者仍需在當前步驟繼續工作。
這種結構化的流程用的並不多。事實上，在我的職業生涯中，我從沒遇到過哪一個團隊使用這種方法，而且我也不認為我能在將來看到這種情況。
我認為其原因是，這種流程帶來很大的開銷，並沒有多少團隊用到它。
然而，如果你開發的軟體生死攸關，會因為有缺陷而讓人喪命，那麼以這種結構化的方式去查詢軟體缺陷就顯得很合理了。
例如，你是為核電站開發軟體。你可能需要一個非常正式的流程去保證最終交出去的程式碼是沒有問題的。
但像我所說，我們大部分開發者所做的軟體都不是危及生命的，因此我們使用一種更加輕量的程式碼審查方法作為正式流程的替代。
所以，讓我們來看看這種輕量級的方法。
輕量級的程式碼審查
如今，輕量級的程式碼審查在開發團隊中很常用。
你可以將輕量級的程式碼審查細分為不同的子類：
- 瞬時的程式碼審查，也稱為結對程式設計(pair programming)；
- 同步的程式碼審查，也稱為即時(over-the-shoulder)程式碼審查；
- 非同步的程式碼審查，也稱為有工具支援的(tool-assisted)程式碼審查；
- 偶爾的程式碼審查，也稱為基於會議的(meeting-based)的程式碼審查。
型別1：瞬時的程式碼審查
第一種型別是瞬時程式碼審查，它發生在結對程式設計的情景中。當一個開發者在敲鍵盤寫程式碼的同時，另一個開發者盯著程式碼，注意著程式碼中潛在的問題，並在此過程中給出提升程式碼質量的建議。
複雜的業務問題
當你需要解決一個複雜問題時，這種程式碼審查的方法很適用。在仔細尋找解決方案的過程中，把兩個人的腦力聚集起來，會增加成功的機率。讓兩個頭腦思考同一個問題，並相互討論可行的方案，這樣你會更可能覆蓋到問題的一些邊界情況。
在遇到需要很多複雜業務邏輯的任務時，我喜歡使用結對程式設計。這樣，有助於兩個人徹底理清流程中的所有不同的可能性，保證所有情況都在程式碼中得到了適當的處理。
與複雜的業務邏輯不同，有時，你也會需要去解決一個複雜的技術問題。例如，你在使用一個新的框架，或者在探索之前你沒用過的一些新技術。在那種情況下，最好還是單獨行動，因為你可以根據自己的情況作出快速調整。為了弄清新技術是如何工作的，你需要上網搜尋大量資料，或者閱讀文件。
這時，結對程式設計的幫助就不大了，因為你們會成為各自獲取這些知識的阻礙。
然而，當你被問題卡住之後，與你的同事交流一下解決方案，往往會幫你獲得看問題的不同視角。
相同的專業水平
考慮進行結對程式設計的另一個重要方面，是一起工作時，兩個開發者的專業水平。兩個開發者最好是處於同一水平，因為這樣他們才能以相同的速度一起工作。
讓一個初級開發者和一個高階開發者進行結對程式設計，效果並不好。在初級開發者負責寫程式碼的時候，坐在旁邊的高階程式設計師可能會因為他寫得太慢了而感到煩惱。如此設定，這個高階程式設計師的能力就被限制住了，從而浪費了時間。
而當鍵盤在高階程式設計師手上時，他又敲得太快，初級程式設計師跟不上高階程式設計師的思路。幾分鐘後，初級程式設計師就迷失在程式碼上下文裡了。
只有當高階程式設計師慢下來，向初級程式設計師解釋清楚他的做法，這種設定才合理。然而，這就不是我們所說的結對程式設計了，而是一種學習的環節，其中高階程式設計師在教初級程式設計師如何解決特定問題。
但是，如果兩個開發者都在同一水平，在這種設定下，他們所能取得的進展是令人驚訝的。其中有一個很大的好處是，兩個開發者能相互激勵，當其中一位失去注意力時，另一位開發者能把他拉回正軌。
總結一下：結對程式設計適用於兩個有相似經驗水平的開發者處理複雜的業務問題的情況。
型別2：同步的程式碼審查
第二種型別是同步的程式碼審查。這種是，一個開發者獨自編寫程式碼，當她寫完程式碼後，立即找程式碼審查者進行審查。
審查者來到開發者的桌前，看著同一塊螢幕，一起審查、討論和改進程式碼。
審查者不清楚程式碼的目標
當審查者不清楚這個任務的目標時，這種程式碼審查型別會很有效果。它會在這種情況下發生：團隊裡沒有優化會議(refinement sessions)，或者sprint計劃會議(sprint planning sessions)，來預先討論每一項任務。
此做法通常會導致一個結果：只有特定的開發人員才知道某項任務的需求。
這樣的情況下，在程式碼審查之前，向審查者介紹一下任務的目標是很有幫助的。
期待大量的程式碼改進
如果程式碼編寫者缺乏經驗，寫出的程式碼需要很大的改進，那麼同步程式碼審查也會很有效。
如果一個經驗豐富的高階開發者將要對一個很初級的程式設計師寫出的一段程式碼進行審查，那麼，當初級程式設計師寫完程式碼後就和高階開發者一起改進這段程式碼，效率是遠遠高於初級程式設計師自己一個人看的。
強行切換思路的缺點
但是同步審查有一大缺點，就是它強行切換了審查者的思路。它不僅讓審查者感到沮喪，也拖慢了整個團隊的效率。
型別3：非同步程式碼審查
然後我們有了第三種型別，非同步程式碼審查。這一型別的審查不是在同一時間、同一塊螢幕上完成的，而是非同步的。開發者在寫完程式碼後，讓這些程式碼對審查者可見，然後開始她的下一個任務。
當審查者有時間了，他會在自己的桌子上按自己的時間表進行程式碼審查。他而不需要當面和開發者溝通，而是用工具寫一些評論。在完成審查後，那些工具會把評論和需要的改動通知給開發者。開發者就會根據評論改進程式碼，同樣的，是以自己的時間表來做這些事情。
這個迴圈，會以程式碼改動再次被提交到審查者這裡而又重新開始。開發者修改程式碼，直到沒有評論說需要改進。最後，改動得到同意，並提交到主分支(master branch)。
你可以看到，同步的程式碼審查和非同步的程式碼審查相比有很大的不同。
沒有直接的依賴
非同步程式碼審查的一大好處， 就是它是非同步發生的。開發者不需要直接依賴於審查者，並且他們都可以按自己的時間表去做各自的工作。
多次審查迴圈的缺點
這裡的缺點就是，你可能會有許多次迴圈的審查，它們可能會持續好幾天，直到最終被接受。
當開發者完成程式碼後，通常需要幾個小時，審查者才開始做程式碼審查。很多時候，審查者給出的建議只有在第二天才能被開發者修復。
這樣，第一次審查週期就至少用掉了一天。如果你又多次這樣的迴圈，審查的時間就延續至一整週了——這還不算寫程式碼和測試的時間。
但這裡有一些做法，可以避免這樣的長時間間隔導致的失控。例如，在我的團隊裡，我們規定，每天上午，每個開發者在開始做其他工作之前，都要先處理積壓的程式碼審查任務。同樣的，在中午午休結束後也需要這樣做。
因為在較長的休息時間後，開發者已經不處在他的程式碼思路中了。這時進行程式碼審查，你並沒有強制它們進行不自然的思路切換，並且能夠讓程式碼在合適的時間得到審查。
對比這種程式碼審查型別的優缺點，我認為，非同步的程式碼審查應該作為每一個專業開發團隊的預設選項。
但在我告訴你為什麼我是這麼想的之前，讓我看看第四種程式碼審查型別。
型別4：偶爾的程式碼審查
很久以前，我曾經每個月會和整個團隊開一次程式碼審查會議。我們坐在會議室，一個開發者展示並解釋著他最近寫的一段困難的程式碼。
其他開發者嘗試尋找著潛在的缺陷，發表評論，給出如何改進程式碼的建議。
我不認為任何團隊和長期地使用偶爾程式碼審查的方式。我只想到這個型別適用於的一種情況：當整個團隊都沒有程式碼審查的經驗時，讓把每個人聚起來，一起做程式碼審查，這樣弄幾次之後，可能會幫助每個人理解程式碼審查的目標和意義。
然而，從長遠來看，這第四種型別並不是一個合適的技術，因為讓全組成員審查一段程式碼是很低效率的做法。
我應該選擇哪種程式碼審查型別呢？
好了，現在你可能會想，該選哪種型別。
我們討論了正式的型別，它顯然不太流行，並且較難用於實踐。
然後，我們討論了輕量級的程式碼審查這一大類，然後是其中著名的4個子型別。
型別1，瞬時的程式碼審查，用於結對程式設計。當兩個開發者有相似的技術組合，並且處理一些複雜的業務問題時，這種方式工作得很好。
型別2，同步的程式碼審查，用於審查者不清楚任務的目標時，需要開發者向其進行解釋的這種情況。當開發者經驗不足，寫出的程式碼需要大量改進時，這種程式碼審查模式也工作得很好。
但是它的缺點是需要強行切換思路，會讓審查者沮喪，以及拖慢團隊開發速度。
型別3，非同步的程式碼審查，避免了強行切換思路帶來的問題，對大多數用例都工作得很好。
型別4，偶爾的程式碼審查，對於專業團隊來說不是一個長期的選擇。可以只在團隊剛剛開始程式碼審查時被使用。
使用非同步程式碼審查作為預設選擇
我認為，專業的團隊應該把非同步的程式碼審查作為預設的選擇。因為它避免了同步程式碼審查的缺陷。
當審查者不能理解開發者做出一項程式碼修改的原因時，可以使用同步的程式碼審查。但在那種情況下，審查者將會去詢問開發者，以獲得額外的資訊和說明。如果你在一個團隊中工作，這樣的情況應該很少發生。
如果你不在一個真正的團隊中，而是和一群人一起工作，那麼同步的程式碼審查就有意義了。如果審查者對你過去這幾天的工作內容毫不知情，那麼在開始一起做程式碼審查之前，向審查者給出一個合適的說明是很合理的。
如果你有兩個開發者，他們具備相似的技能組合，並且在攻克一個複雜的業務問題，那麼也有理由切換到結對程式設計的模式。但是，一個團隊往往由許多經驗水平不同的成員組成，並且不會一直都在處理複雜的業務問題。大多數時間，你手上是複雜度在平均水平的常規任務。
因此，專業團隊的最佳選擇是：使用非同步的程式碼審查作為預設選擇，然後當需要時切換到同步的程式碼審查或者結對程式設計。
好了，這就是今天的內容。
你的團隊使用什麼程式碼審查的型別呢？你知道其他的、我這裡漏掉的程式碼審查型別嗎？請在評論裡讓我知道吧。
下次再聊。保重。