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

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

轉(zhuǎn)載請注明出處：葡萄城官網(wǎng)，葡萄城為開發(fā)者提供專業(yè)的開發(fā)工具、解決方案和服務(wù)，賦能開發(fā)者。

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

下文闡述了4種主流的代碼審查(code review)類型，相信作為專業(yè)的開發(fā)人員，你應(yīng)該都了解它們！

每個專業(yè)的軟件開發(fā)者都知道，代碼審查是任何正式開發(fā)過程中的必要環(huán)節(jié)。但大多數(shù)開發(fā)者不知道的是，代碼審查分為很多種類型。根據(jù)你項目和團隊架構(gòu)的不同，每一種代碼審查類型都有它特有的優(yōu)缺點。

我將在本文列出幾種代碼的審查的類型，并詳細解釋它們各自是如何工作的。并且，我也將對你在何時做出哪種選擇給出一些建議。

好了，讓我們開始吧。

首先，在一個很高的層面，你可以將代碼審查歸為兩大類：正式的代碼審查(formal code review)，和輕量級的代碼審查(light weight code review)。

正式的代碼審查是基于正式的開發(fā)流程。其中最流行的實踐是范根檢查法(Fagan inspection)。

它為試圖尋找代碼的缺陷提供了一種非常結(jié)構(gòu)化的流程，并且，它還可以用于發(fā)現(xiàn)規(guī)范(specifications)中的或者設(shè)計中的缺陷。

范根檢查法由6個步驟組成：計劃(Planning)，概述(Overview)，準備(Preparation)，召開檢查會議(Inspection Meeting)，重做(Rework)，和追查(Follow-up)?；镜乃枷胧牵侯A(yù)先制定好每一個步驟所需要達到的輸出要求。接下來，當進行到某個過程時，你檢查其現(xiàn)在的輸出，并與之前制定的理想輸出要求做比較。然后，你由此來決定，是否進入下一個步驟，或者仍需在當前步驟繼續(xù)工作。

這種結(jié)構(gòu)化的流程用的并不多。事實上，在我的職業(yè)生涯中，我從沒遇到過哪一個團隊使用這種方法，而且我也不認為我能在將來看到這種情況。

我認為其原因是，這種流程帶來很大的開銷，并沒有多少團隊用到它。

然而，如果你開發(fā)的軟件生死攸關(guān)，會因為有缺陷而讓人喪命，那么以這種結(jié)構(gòu)化的方式去查找軟件缺陷就顯得很合理了。

例如，你是為核電站開發(fā)軟件。你可能需要一個非常正式的流程去保證最終交出去的代碼是沒有問題的。

但像我所說，我們大部分開發(fā)者所做的軟件都不是危及生命的，因此我們使用一種更加輕量的代碼審查方法作為正式流程的替代。

所以，讓我們來看看這種輕量級的方法。

如今，輕量級的代碼審查在開發(fā)團隊中很常用。

你可以將輕量級的代碼審查細分為不同的子類：

瞬時的代碼審查，也稱為結(jié)對編程(pair programming)；

同步的代碼審查，也稱為即時(over-the-shoulder)代碼審查；

異步的代碼審查，也稱為有工具支持的(tool-assisted)代碼審查；

偶爾的代碼審查，也稱為基于會議的(meeting-based)的代碼審查。

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

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

在遇到需要很多復(fù)雜業(yè)務(wù)邏輯的任務(wù)時，我喜歡使用結(jié)對編程。這樣，有助于兩個人徹底理清流程中的所有不同的可能性，保證所有情況都在代碼中得到了適當?shù)奶幚怼?/p>

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

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

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

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

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

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

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

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

總結(jié)一下：結(jié)對編程適用于兩個有相似經(jīng)驗水平的開發(fā)者處理復(fù)雜的業(yè)務(wù)問題的情況。

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

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

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

此做法通常會導(dǎo)致一個結(jié)果：只有特定的開發(fā)人員才知道某項任務(wù)的需求。

這樣的情況下，在代碼審查之前，向?qū)彶檎呓榻B一下任務(wù)的目標是很有幫助的。

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

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

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

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

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

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

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

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

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

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

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

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

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

對比這種代碼審查類型的優(yōu)缺點，我認為，異步的代碼審查應(yīng)該作為每一個專業(yè)開發(fā)團隊的默認選項。

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

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

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

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

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

好了，現(xiàn)在你可能會想，該選哪種類型。

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

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

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

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

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

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

類型4，偶爾的代碼審查，對于專業(yè)團隊來說不是一個長期的選擇?？梢灾辉趫F隊剛剛開始代碼審查時被使用。

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

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

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

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

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

好了，這就是今天的內(nèi)容。

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

下次再聊。保重。

本文是由葡萄城技術(shù)開發(fā)團隊發(fā)布，轉(zhuǎn)載請注明出處：葡萄城官網(wǎng)

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

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

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