做爲開發人員，這四類Code Review方法你都知道嗎？

本文翻譯自：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)。基本的思想是：預先制定好每個步驟所須要達到的輸出要求。接下來，當進行到某個過程時，你檢查其如今的輸出，並與以前制定的理想輸出要求作比較。而後，你由此來決定，是否進入下一個步驟，或者仍需在當前步驟繼續工做。

這種結構化的流程用的並很少。事實上，在個人職業生涯中，我從沒遇到過哪個團隊使用這種方法，並且我也不認爲我能在未來看到這種狀況。

我認爲其緣由是，這種流程帶來很大的開銷，並無多少團隊用到它。

然而，若是你開發的軟件生死攸關，會由於有缺陷而讓人喪命，那麼以這種結構化的方式去查找軟件缺陷就顯得很合理了。

例如，你是爲核電站開發軟件。你可能須要一個很是正式的流程去保證最終交出去的代碼是沒有問題的。

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

因此，讓咱們來看看這種輕量級的方法。

輕量級的代碼審查

現在，輕量級的代碼審查在開發團隊中很經常使用。

你能夠將輕量級的代碼審查細分爲不一樣的子類：

1. 瞬時的代碼審查，也稱爲結對編程(pair programming)；
2. 同步的代碼審查，也稱爲即時(over-the-shoulder)代碼審查；
3. 異步的代碼審查，也稱爲有工具支持的(tool-assisted)代碼審查；
4. 偶爾的代碼審查，也稱爲基於會議的(meeting-based)的代碼審查。

類型1：瞬時的代碼審查

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

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

在遇到須要不少複雜業務邏輯的任務時，我喜歡使用結對編程。這樣，有助於兩我的完全理清流程中的全部不一樣的可能性，保證全部狀況都在代碼中獲得了適當的處理。

與複雜的業務邏輯不一樣，有時，你也會須要去解決一個複雜的技術問題。例如，你在使用一個新的框架，或者在探索以前你沒用過的一些新技術。在那種狀況下，最好仍是單獨行動，由於你能夠根據本身的狀況做出快速調整。爲了弄清新技術是如何工做的，你須要上網搜索大量資料，或者閱讀文檔。

這時，結對編程的幫助就不大了，由於大家會成爲各自獲取這些知識的阻礙。

然而，當你被問題卡住以後，與你的同事交流一下解決方案，每每會幫你得到看問題的不一樣視角。

相同的專業水平
考慮進行結對編程的另外一個重要方面，是一塊兒工做時，兩個開發者的專業水平。兩個開發者最好是處於同一水平，由於這樣他們才能以相同的速度一塊兒工做。

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

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

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

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

總結一下：結對編程適用於兩個有類似經驗水平的開發者處理複雜的業務問題的狀況。

類型2：同步的代碼審查

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

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

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

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

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

期待大量的代碼改進
若是代碼編寫者缺少經驗，寫出的代碼須要很大的改進，那麼同步代碼審查也會頗有效。

若是一個經驗豐富的高級開發者將要對一個很初級的程序員寫出的一段代碼進行審查，那麼，當初級程序員寫完代碼後就和高級開發者一塊兒改進這段代碼，效率是遠遠高於初級程序員本身一我的看的。

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

類型3：異步代碼審查

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

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

這個循環，會以代碼改動再次被提交到審查者這裏而又從新開始。開發者修改代碼，直到沒有評論說須要改進。最後，改動獲得贊成，並提交到主分支(master branch)。

你能夠看到，同步的代碼審查和異步的代碼審查相比有很大的不一樣。

沒有直接的依賴
異步代碼審查的一大好處， 就是它是異步發生的。開發者不須要直接依賴於審查者，而且他們均可以按本身的時間表去作各自的工做。

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

當開發者完成代碼後，一般須要幾個小時，審查者纔開始作代碼審查。不少時候，審查者給出的建議只有在次日才能被開發者修復。

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

但這裏有一些作法，能夠避免這樣的長時間間隔致使的失控。例如，在個人團隊裏，咱們規定，天天上午，每一個開發者在開始作其餘工做以前，都要先處理積壓的代碼審查任務。一樣的，在中午午休結束後也須要這樣作。

由於在較長的休息時間後，開發者已經不處在他的代碼思路中了。這時進行代碼審查，你並無強制它們進行不天然的思路切換，而且可以讓代碼在合適的時間獲得審查。

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

但在我告訴你爲何我是這麼想的以前，讓我看看第四種代碼審查類型。

類型4：偶爾的代碼審查

好久之前，我曾經每月會和整個團隊開一次代碼審查會議。咱們坐在會議室，一個開發者展現並解釋着他最近寫的一段困難的代碼。

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

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

然而，從長遠來看，這第四種類型並非一個合適的技術，由於讓全組成員審查一段代碼是很低效率的作法。

我應該選擇哪一種代碼審查類型呢？

好了，如今你可能會想，該選哪一種類型。

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

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

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

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

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

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

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

使用異步代碼審查做爲默認選擇

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

當審查者不能理解開發者作出一項代碼修改的緣由時，可使用同步的代碼審查。但在那種狀況下，審查者將會去詢問開發者，以得到額外的信息和說明。若是你在一個團隊中工做，這樣的狀況應該不多發生。

若是你不在一個真正的團隊中，而是和一羣人一塊兒工做，那麼同步的代碼審查就有意義了。若是審查者對你過去這幾天的工做內容絕不知情，那麼在開始一塊兒作代碼審查以前，向審查者給出一個合適的說明是很合理的。

若是你有兩個開發者，他們具有類似的技能組合，而且在攻克一個複雜的業務問題，那麼也有理由切換到結對編程的模式。可是，一個團隊每每由許多經驗水平不一樣的成員組成，而且不會一直都在處理複雜的業務問題。大多數時間，你手上是複雜度在平均水平的常規任務。

所以，專業團隊的最佳選擇是：使用異步的代碼審查做爲默認選擇，而後當須要時切換到同步的代碼審查或者結對編程。

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

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

下次再聊。保重。

---

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

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

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

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