摘要：類型瞬時的代碼審查第一種類型是瞬時代碼審查，它發生在結對編程的情景中。相同的專業水平考慮進行結對編程的另一個重要方面，是一起工作時，兩個開發者的專業水平。讓一個初級開發者和一個高級開發者進行結對編程，效果并不好。

本文翻譯自：https://dzone.com/articles/4-...

轉載請注明出處：葡萄城官網，葡萄城為開發者提供專業的開發工具、解決方案和服務，賦能開發者。

沒有人能保證他產出的代碼一定是完美的，就連從事控件開發20年的葡萄城高級軟件開發工程師在推出每款產品的新功能時，都要進行數百次的黑白盒測試和壓力測試。比如，SpreadJS的Redo/Undo功能，在設計之初，用戶必須使用多個功能和內置函數，才能處理自定義命令的撤消和重做操作，如今，用戶只需要定義“執行”功能，就可以輕松實現。

下文闡述了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)的代碼審查。

第一種類型是瞬時代碼審查，它發生在結對編程的情景中。當一個開發者在敲鍵盤寫代碼的同時，另一個開發者盯著代碼，注意著代碼中潛在的問題，并在此過程中給出提升代碼質量的建議。

復雜的業務問題
當你需要解決一個復雜問題時，這種代碼審查的方法很適用。在仔細尋找解決方案的過程中，把兩個人的腦力聚集起來，會增加成功的幾率。讓兩個頭腦思考同一個問題，并相互討論可行的方案，這樣你會更可能覆蓋到問題的一些邊界情況。

在遇到需要很多復雜業務邏輯的任務時，我喜歡使用結對編程。這樣，有助于兩個人徹底理清流程中的所有不同的可能性，保證所有情況都在代碼中得到了適當的處理。

與復雜的業務邏輯不同，有時，你也會需要去解決一個復雜的技術問題。例如，你在使用一個新的框架，或者在探索之前你沒用過的一些新技術。在那種情況下，最好還是多帶帶行動，因為你可以根據自己的情況作出快速調整。為了弄清新技術是如何工作的，你需要上網搜索大量資料，或者閱讀文檔。

這時，結對編程的幫助就不大了，因為你們會成為各自獲取這些知識的阻礙。

然而，當你被問題卡住之后，與你的同事交流一下解決方案，往往會幫你獲得看問題的不同視角。

相同的專業水平
考慮進行結對編程的另一個重要方面，是一起工作時，兩個開發者的專業水平。兩個開發者最好是處于同一水平，因為這樣他們才能以相同的速度一起工作。

讓一個初級開發者和一個高級開發者進行結對編程，效果并不好。在初級開發者負責寫代碼的時候，坐在旁邊的高級程序員可能會因為他寫得太慢了而感到煩惱。如此設定，這個高級程序員的能力就被限制住了，從而浪費了時間。

而當鍵盤在高級程序員手上時，他又敲得太快，初級程序員跟不上高級程序員的思路。幾分鐘后，初級程序員就迷失在代碼上下文里了。

只有當高級程序員慢下來，向初級程序員解釋清楚他的做法，這種設定才合理。然而，這就不是我們所說的結對編程了，而是一種學習的環節，其中高級程序員在教初級程序員如何解決特定問題。

但是，如果兩個開發者都在同一水平，在這種設定下，他們所能取得的進展是令人驚訝的。其中有一個很大的好處是，兩個開發者能相互激勵，當其中一位失去注意力時，另一位開發者能把他拉回正軌。

總結一下：結對編程適用于兩個有相似經驗水平的開發者處理復雜的業務問題的情況。

第二種類型是同步的代碼審查。這種是，一個開發者獨自編寫代碼，當她寫完代碼后，立即找代碼審查者進行審查。

審查者來到開發者的桌前，看著同一塊屏幕，一起審查、討論和改進代碼。

審查者不清楚代碼的目標
當審查者不清楚這個任務的目標時，這種代碼審查類型會很有效果。它會在這種情況下發生：團隊里沒有優化會議(refinement sessions)，或者sprint計劃會議(sprint planning sessions)，來預先討論每一項任務。

此做法通常會導致一個結果：只有特定的開發人員才知道某項任務的需求。

這樣的情況下，在代碼審查之前，向審查者介紹一下任務的目標是很有幫助的。

期待大量的代碼改進
如果代碼編寫者缺乏經驗，寫出的代碼需要很大的改進，那么同步代碼審查也會很有效。

如果一個經驗豐富的高級開發者將要對一個很初級的程序員寫出的一段代碼進行審查，那么，當初級程序員寫完代碼后就和高級開發者一起改進這段代碼，效率是遠遠高于初級程序員自己一個人看的。

強行切換思路的缺點
但是同步審查有一大缺點，就是它強行切換了審查者的思路。它不僅讓審查者感到沮喪，也拖慢了整個團隊的效率。

然后我們有了第三種類型，異步代碼審查。這一類型的審查不是在同一時間、同一塊屏幕上完成的，而是異步的。開發者在寫完代碼后，讓這些代碼對審查者可見，然后開始她的下一個任務。

當審查者有時間了，他會在自己的桌子上按自己的時間表進行代碼審查。他而不需要當面和開發者溝通，而是用工具寫一些評論。在完成審查后，那些工具會把評論和需要的改動通知給開發者。開發者就會根據評論改進代碼，同樣的，是以自己的時間表來做這些事情。

這個循環，會以代碼改動再次被提交到審查者這里而又重新開始。開發者修改代碼，直到沒有評論說需要改進。最后，改動得到同意，并提交到主分支(master branch)。

你可以看到，同步的代碼審查和異步的代碼審查相比有很大的不同。

沒有直接的依賴
異步代碼審查的一大好處， 就是它是異步發生的。開發者不需要直接依賴于審查者，并且他們都可以按自己的時間表去做各自的工作。

多次審查循環的缺點
這里的缺點就是，你可能會有許多次循環的審查，它們可能會持續好幾天，直到最終被接受。

當開發者完成代碼后，通常需要幾個小時，審查者才開始做代碼審查。很多時候，審查者給出的建議只有在第二天才能被開發者修復。

這樣，第一次審查周期就至少用掉了一天。如果你又多次這樣的循環，審查的時間就延續至一整周了——這還不算寫代碼和測試的時間。

但這里有一些做法，可以避免這樣的長時間間隔導致的失控。例如，在我的團隊里，我們規定，每天上午，每個開發者在開始做其他工作之前，都要先處理積壓的代碼審查任務。同樣的，在中午午休結束后也需要這樣做。

因為在較長的休息時間后，開發者已經不處在他的代碼思路中了。這時進行代碼審查，你并沒有強制它們進行不自然的思路切換，并且能夠讓代碼在合適的時間得到審查。

對比這種代碼審查類型的優缺點，我認為，異步的代碼審查應該作為每一個專業開發團隊的默認選項。

但在我告訴你為什么我是這么想的之前，讓我看看第四種代碼審查類型。

很久以前，我曾經每個月會和整個團隊開一次代碼審查會議。我們坐在會議室，一個開發者展示并解釋著他最近寫的一段困難的代碼。

其他開發者嘗試尋找著潛在的缺陷，發表評論，給出如何改進代碼的建議。

我不認為任何團隊和長期地使用偶爾代碼審查的方式。我只想到這個類型適用于的一種情況：當整個團隊都沒有代碼審查的經驗時，讓把每個人聚起來，一起做代碼審查，這樣弄幾次之后，可能會幫助每個人理解代碼審查的目標和意義。

然而，從長遠來看，這第四種類型并不是一個合適的技術，因為讓全組成員審查一段代碼是很低效率的做法。

好了，現在你可能會想，該選哪種類型。

我們討論了正式的類型，它顯然不太流行，并且較難用于實踐。

然后，我們討論了輕量級的代碼審查這一大類，然后是其中著名的4個子類型。

類型1，瞬時的代碼審查，用于結對編程。當兩個開發者有相似的技術組合，并且處理一些復雜的業務問題時，這種方式工作得很好。

類型2，同步的代碼審查，用于審查者不清楚任務的目標時，需要開發者向其進行解釋的這種情況。當開發者經驗不足，寫出的代碼需要大量改進時，這種代碼審查模式也工作得很好。

但是它的缺點是需要強行切換思路，會讓審查者沮喪，以及拖慢團隊開發速度。

類型3，異步的代碼審查，避免了強行切換思路帶來的問題，對大多數用例都工作得很好。

類型4，偶爾的代碼審查，對于專業團隊來說不是一個長期的選擇。可以只在團隊剛剛開始代碼審查時被使用。

我認為，專業的團隊應該把異步的代碼審查作為默認的選擇。因為它避免了同步代碼審查的缺陷。

當審查者不能理解開發者做出一項代碼修改的原因時，可以使用同步的代碼審查。但在那種情況下，審查者將會去詢問開發者，以獲得額外的信息和說明。如果你在一個團隊中工作，這樣的情況應該很少發生。

如果你不在一個真正的團隊中，而是和一群人一起工作，那么同步的代碼審查就有意義了。如果審查者對你過去這幾天的工作內容毫不知情，那么在開始一起做代碼審查之前，向審查者給出一個合適的說明是很合理的。

如果你有兩個開發者，他們具備相似的技能組合，并且在攻克一個復雜的業務問題，那么也有理由切換到結對編程的模式。但是，一個團隊往往由許多經驗水平不同的成員組成，并且不會一直都在處理復雜的業務問題。大多數時間，你手上是復雜度在平均水平的常規任務。

因此，專業團隊的最佳選擇是：使用異步的代碼審查作為默認選擇，然后當需要時切換到同步的代碼審查或者結對編程。

好了，這就是今天的內容。

你的團隊使用什么代碼審查的類型呢？你知道其他的、我這里漏掉的代碼審查類型嗎？請在評論里讓我知道吧。

下次再聊。保重。

本文是由葡萄城技術開發團隊發布，轉載請注明出處：葡萄城官網

了解支持Angular、React 和 Vue 的純前端控件集，請前往 WijmoJS

了解可嵌入您系統的在線 Excel，請前往 SpreadJS純前端表格控件

了解最全面的.NET控件集，請前往 ComponentOne .NET開發的瑞士軍刀