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

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

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

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

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

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

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

好了，讓我們開(kāi)始吧。

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

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

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

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

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

我認(rèn)為其原因是，這種流程帶來(lái)很大的開(kāi)銷，并沒(méi)有多少團(tuán)隊(duì)用到它。

然而，如果你開(kāi)發(fā)的軟件生死攸關(guān)，會(huì)因?yàn)橛腥毕荻屓藛拭敲匆赃@種結(jié)構(gòu)化的方式去查找軟件缺陷就顯得很合理了。

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

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

所以，讓我們來(lái)看看這種輕量級(jí)的方法。

如今，輕量級(jí)的代碼審查在開(kāi)發(fā)團(tuán)隊(duì)中很常用。

你可以將輕量級(jí)的代碼審查細(xì)分為不同的子類：

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

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

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

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

第一種類型是瞬時(shí)代碼審查，它發(fā)生在結(jié)對(duì)編程的情景中。當(dāng)一個(gè)開(kāi)發(fā)者在敲鍵盤(pán)寫(xiě)代碼的同時(shí)，另一個(gè)開(kāi)發(fā)者盯著代碼，注意著代碼中潛在的問(wèn)題，并在此過(guò)程中給出提升代碼質(zhì)量的建議。

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

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

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

這時(shí)，結(jié)對(duì)編程的幫助就不大了，因?yàn)槟銈儠?huì)成為各自獲取這些知識(shí)的阻礙。

然而，當(dāng)你被問(wèn)題卡住之后，與你的同事交流一下解決方案，往往會(huì)幫你獲得看問(wèn)題的不同視角。

相同的專業(yè)水平
考慮進(jìn)行結(jié)對(duì)編程的另一個(gè)重要方面，是一起工作時(shí)，兩個(gè)開(kāi)發(fā)者的專業(yè)水平。兩個(gè)開(kāi)發(fā)者最好是處于同一水平，因?yàn)檫@樣他們才能以相同的速度一起工作。

讓一個(gè)初級(jí)開(kāi)發(fā)者和一個(gè)高級(jí)開(kāi)發(fā)者進(jìn)行結(jié)對(duì)編程，效果并不好。在初級(jí)開(kāi)發(fā)者負(fù)責(zé)寫(xiě)代碼的時(shí)候，坐在旁邊的高級(jí)程序員可能會(huì)因?yàn)樗麑?xiě)得太慢了而感到煩惱。如此設(shè)定，這個(gè)高級(jí)程序員的能力就被限制住了，從而浪費(fèi)了時(shí)間。

而當(dāng)鍵盤(pán)在高級(jí)程序員手上時(shí)，他又敲得太快，初級(jí)程序員跟不上高級(jí)程序員的思路。幾分鐘后，初級(jí)程序員就迷失在代碼上下文里了。

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

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

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

第二種類型是同步的代碼審查。這種是，一個(gè)開(kāi)發(fā)者獨(dú)自編寫(xiě)代碼，當(dāng)她寫(xiě)完代碼后，立即找代碼審查者進(jìn)行審查。

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

審查者不清楚代碼的目標(biāo)
當(dāng)審查者不清楚這個(gè)任務(wù)的目標(biāo)時(shí)，這種代碼審查類型會(huì)很有效果。它會(huì)在這種情況下發(fā)生：團(tuán)隊(duì)里沒(méi)有優(yōu)化會(huì)議(refinement sessions)，或者sprint計(jì)劃會(huì)議(sprint planning sessions)，來(lái)預(yù)先討論每一項(xiàng)任務(wù)。

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

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

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

如果一個(gè)經(jīng)驗(yàn)豐富的高級(jí)開(kāi)發(fā)者將要對(duì)一個(gè)很初級(jí)的程序員寫(xiě)出的一段代碼進(jìn)行審查，那么，當(dāng)初級(jí)程序員寫(xiě)完代碼后就和高級(jí)開(kāi)發(fā)者一起改進(jìn)這段代碼，效率是遠(yuǎn)遠(yuǎn)高于初級(jí)程序員自己一個(gè)人看的。

強(qiáng)行切換思路的缺點(diǎn)
但是同步審查有一大缺點(diǎn)，就是它強(qiáng)行切換了審查者的思路。它不僅讓審查者感到沮喪，也拖慢了整個(gè)團(tuán)隊(duì)的效率。

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

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

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

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

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

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

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

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

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

因?yàn)樵谳^長(zhǎng)的休息時(shí)間后，開(kāi)發(fā)者已經(jīng)不處在他的代碼思路中了。這時(shí)進(jìn)行代碼審查，你并沒(méi)有強(qiáng)制它們進(jìn)行不自然的思路切換，并且能夠讓代碼在合適的時(shí)間得到審查。

對(duì)比這種代碼審查類型的優(yōu)缺點(diǎn)，我認(rèn)為，異步的代碼審查應(yīng)該作為每一個(gè)專業(yè)開(kāi)發(fā)團(tuán)隊(duì)的默認(rèn)選項(xiàng)。

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

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

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

我不認(rèn)為任何團(tuán)隊(duì)和長(zhǎng)期地使用偶爾代碼審查的方式。我只想到這個(gè)類型適用于的一種情況：當(dāng)整個(gè)團(tuán)隊(duì)都沒(méi)有代碼審查的經(jīng)驗(yàn)時(shí)，讓把每個(gè)人聚起來(lái)，一起做代碼審查，這樣弄幾次之后，可能會(huì)幫助每個(gè)人理解代碼審查的目標(biāo)和意義。

然而，從長(zhǎng)遠(yuǎn)來(lái)看，這第四種類型并不是一個(gè)合適的技術(shù)，因?yàn)樽屓M成員審查一段代碼是很低效率的做法。

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

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

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

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

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

但是它的缺點(diǎn)是需要強(qiáng)行切換思路，會(huì)讓審查者沮喪，以及拖慢團(tuán)隊(duì)開(kāi)發(fā)速度。

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

類型4，偶爾的代碼審查，對(duì)于專業(yè)團(tuán)隊(duì)來(lái)說(shuō)不是一個(gè)長(zhǎng)期的選擇?？梢灾辉趫F(tuán)隊(duì)剛剛開(kāi)始代碼審查時(shí)被使用。

我認(rèn)為，專業(yè)的團(tuán)隊(duì)?wèi)?yīng)該把異步的代碼審查作為默認(rèn)的選擇。因?yàn)樗苊饬送酱a審查的缺陷。

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

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

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

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

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

你的團(tuán)隊(duì)使用什么代碼審查的類型呢？你知道其他的、我這里漏掉的代碼審查類型嗎？請(qǐng)?jiān)谠u(píng)論里讓我知道吧。

下次再聊。保重。

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

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

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

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