沒有人能保證他產出的代碼一定是完美的。下文闡述了4種主流的代碼審查(code review)類型，相信作爲專業的開發人員，你應該都瞭解它們！
每個專業的軟件開發者都知道，代碼審查是任何正式開發過程中的必要環節。但大多數開發者不知道的是，代碼審查分爲很多種類型。根據你項目和團隊架構的不同，每一種代碼審查類型都有它特有的優缺點。
我將在本文列出幾種代碼的審查的類型，並詳細解釋它們各自是如何工作的。並且，我也將對你在何時做出哪種選擇給出一些建議，想學習更多的同學可以夾裙四九九七五四六一四，備註cs。
好了，讓我們開始吧。
首先，在一個很高的層面，你可以將代碼審查歸爲兩大類：正式的代碼審查(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，偶爾的代碼審查，對於專業團隊來說不是一個長期的選擇。可以只在團隊剛剛開始代碼審查時被使用。
使用異步代碼審查作爲默認選擇
我認爲，專業的團隊應該把異步的代碼審查作爲默認的選擇。因爲它避免了同步代碼審查的缺陷。
當審查者不能理解開發者做出一項代碼修改的原因時，可以使用同步的代碼審查。但在那種情況下，審查者將會去詢問開發者，以獲得額外的信息和說明。如果你在一個團隊中工作，這樣的情況應該很少發生。
如果你不在一個真正的團隊中，而是和一羣人一起工作，那麼同步的代碼審查就有意義了。如果審查者對你過去這幾天的工作內容毫不知情，那麼在開始一起做代碼審查之前，向審查者給出一個合適的說明是很合理的。
如果你有兩個開發者，他們具備相似的技能組合，並且在攻克一個複雜的業務問題，那麼也有理由切換到結對編程的模式。但是，一個團隊往往由許多經驗水平不同的成員組成，並且不會一直都在處理複雜的業務問題。大多數時間，你手上是複雜度在平均水平的常規任務。
因此，專業團隊的最佳選擇是：使用異步的代碼審查作爲默認選擇，然後當需要時切換到同步的代碼審查或者結對編程。
好了，這就是今天的內容。
你的團隊使用什麼代碼審查的類型呢？你知道其他的、我這裏漏掉的代碼審查類型嗎？請在評論裏讓我知道吧。
下次再聊。保重。