微軟是如何做 Code Review 的

• 2019 年 11 月 14 日
• 筆記

作者 | Dr. Michaela Greiler

翻譯 | 漫慢忙

本文翻譯自 Dr. Michaela Greiler 的 How Code Reviews work at Microsoft，作者所在的團隊調研了微軟是如何做程式碼審查的，並做了相關的總結。原文附有大量鏈接資源，在此沒有整理出來，相關鏈接可以查看原文獲取

您是否曾經想過全球最大的軟體公司之一是如何通過程式碼審查來確保高品質程式碼？

我也是。因此，我與同事一起調查了 Microsoft 是如何進行程式碼審查的。他們的做法是常見的做法嗎？開發人員是否需要進行程式碼審查？他們使用哪些工具？讓我們在這篇文章中找到答案。

首先，讓我為您提供一些有關 Microsoft 的關鍵資訊。微軟大約有 140,000 名員工。其中約有 44％，即超過 60,000 名員工是工程師。成千上萬的工程師同時使用相同的程式碼庫來開發 Office，Visual Studio 或 Windows 等幾種產品。

可以想像，確保不同子團隊開發的程式碼可以完美地協同工作是一項艱巨的任務。在 Microsoft 中，程式碼審查起著重要作用，確保可以在如此大規模的範圍內實現順暢的協作。

Microsoft 的程式碼審查是開發過程中不可或缺的一部分

在 Microsoft，程式碼審查是一種被廣泛採用的工程實踐。絕大多數工程師認為這是一個很好的最佳實踐。而且大多數高效能團隊都花了大量時間進行程式碼審查。

關於 Microsoft 程式碼審查的一個調查

因為程式碼審查在 Microsoft 開發過程中起著如此重要的作用，所以它是我們深入研究並真正了解這種做法利弊的理想目標。在 Microsoft 進行的有關程式碼審查的大規模研究中，我們採訪、觀察和調查了 900 多名開發人員的程式碼審查實踐。

我們的目的是了解 Microsoft 如何進行精確的程式碼審查。我們想知道，開發人員在進行程式碼審查時會遇到哪些程式碼審查陷阱，以及他們為克服這些挑戰而開發的程式碼審查最佳實踐。

您可以從 Microsoft 的程式碼審查實踐中學到什麼？

大多數經驗教訓都是非常有價值的，不管對於小型團隊和組織，還是對於大型團隊和組織。如果你的團隊還沒有進行程式碼審查，那麼我們會向您展示我們的發現以及程式碼審查的好處。我還將解釋程式碼審查生命周期，以便您可以將這種實踐納入自己的開發過程中。

如果你的團隊已經施行了程式碼審查，則可以將您的實踐與 Microsoft 的程式碼審查實踐進行比較。您的程式碼審查生命周期看起來是否有所不同？在下一篇文章中，我們將介紹程式碼審查陷阱和程式碼審查最佳實踐。有了這些資訊，您就可以開始查看您的團隊是否已經實施了我介紹的所有最佳實踐並克服了挑戰。現在讓我們開始吧。

Microsoft 工程師多久做一次程式碼審查？

在這項研究中，有 36％ 的開發人員表示他們一天執行多次程式碼審查。另有 39％ 的開發人員表示，他們每天至少進行一次程式碼審查。12％ 的人每周進行多次程式碼審查，只有 13％ 的人說他們在過去一周未進行程式碼審查。

這意味著 Microsoft 的開發人員將大量時間花費在程式碼審查上。因此，重要的是要確保這段時間是值得花費。那麼，程式碼審查有哪些好處？

程式碼審查有哪些好處？

開發人員提到，程式碼審查最大的好處是提高程式碼品質並發現程式碼中的缺陷。程式碼審查的另一個重要好處是知識轉移。

知識轉移意味著互相檢查程式碼的團隊成員會熟悉大部分程式碼庫。這也意味著程式碼審查最佳實踐是在團隊內部不斷發展形成的。另一個優勢是，新團隊成員和初級開發人員可以在查看或獲得回饋的同時學習和提高他們的編碼技能。

如果開發人員在程式碼審查期間討論替代解決方案，則不僅會改善程式碼庫，而且對所有相關人員都有學習作用。因此，學習、指導和自我完善是 Microsoft 將程式碼審查視為有益實踐的原因。

開發人員通常如何進行程式碼審查？

程式碼審查可以通過多種方式執行。可以是一個開發人員走到另一個開發人員的辦公桌前一起看一些程式碼，也可以是團隊一起檢查程式碼。但是，在 Microsoft 進行程式碼審查時，最有可能遇到的情況是程式碼審查是藉助工具完成的。

Microsoft 的程式碼審查通常是通過內部工具完成的

有各種各樣的程式碼審查工具可用，並且在 Microsoft，團隊可以自由選擇他們的工具。在 2016 年，89％ 的開發人員表示是使用 CodeFlow 程式碼審查工具。稍後，我將解釋有關此程式碼檢查工具的更多資訊。從那時起，隨著 Git 的崛起，工具的使用也發生了變化。讓我們考慮一個典型的審查情況：

讓我們想像一下 Microsoft 的一名開發人員，讓我們暫且稱她為 Rose。Rose 剛剛完成了功能的一部分，現在希望獲得同事的回饋。

Rose 如何在 Microsoft 進行程式碼審查？

好了，Rose 準備獲得一些回饋。因此，她首先準備好程式碼以進行審查。此步驟包括她打開程式碼檢查工具，預覽程式碼的更改。程式碼審查工具執行一些對比任務，這些任務可以幫助 Rose 準確查看她所做的更改。

在仔細檢查了這些更改之後，她準備了一些說明，告訴審閱者她做了什麼以及為什麼這麼做。這個說明可幫助審閱者了解程式碼更改的目的及其動機。現在，可以將程式碼發送給審閱者了。

Rose 如何選擇合適的程式碼審閱者？

許多經驗豐富的開發人員都知道誰應該參加程式碼審查。但是，對於團隊中的新成員或新的工作領域，選擇起來可能會比較棘手。如果 Rose 不知道自己應該添加誰，她可以查看團隊的相關政策或詢問同事。她還可以使用程式碼審查工具的推薦功能，該功能可幫助她來選擇審閱者。

誰是相關的審閱者？

Rose 選擇了她認為可以為這段程式碼貢獻知識的審閱者。審閱者通常是其他開發人員，但也可以包括其他利益相關者，例如 dev-ops 工程師，UI 或管理人員。審閱者被選擇可能是因為他們的專業知識，也可能是他們需要隨時了解即將到來的變更。

Rose 要求審閱者提供回饋

一旦選好了審閱者，Rose 就會發送程式碼審查請求。程式碼審查工具會自動發送通知，以通知審閱者已創建了新的程式碼審查。通知將發送給所有審閱者。但是，通常團隊的經理或產品經理也會添加到通知列表中，並為每次審閱自動通知他們。這些通知使他們能夠了解到相關資訊，不過他們不需要執行審核。

接收回饋是一個反覆的過程

一旦 Rose 的同事有時間，他們將查看程式碼審查。每個審閱者都可以在程式碼中添加註釋和評論。完成評審後，審閱者會將帶注釋的程式碼發送回 Rose。Rose 現在可以處理這些評論，並準備程式碼的新版本。

審閱者通常會查看一些資訊：程式碼看起來是否有錯誤嗎？有架構上的問題嗎？是否有一些小問題，例如缺少說明、拼寫錯誤等？並非所有評論都同樣有價值。但是，有幾種最佳實踐可提高程式碼審查注釋的價值。

Rose 準備了程式碼的新版本

Rose 通過修正和解決建議來處理回饋。如果 Rose 發現存在一些誤解或其他有爭議的問題，她可能會去找同事親自討論。這有時比通過工具更容易，更個性化。

無論如何，一旦她處理完所有回饋，就將程式碼的新版本發送給審閱者。該新的改進版本稱為修訂版。

如果需要，她將收到進一步的回饋。這種迭代是否持續幾次取決於更改的類型及其品質。對於簡單和小的程式碼更改，通常只需要一個程式碼審閱修訂。對於其他更複雜的更改或有問題的程式碼中的更改，可能需要幾次迭代。

這是完全正常的，一部分原因是這個程式碼審閱回饋周期能激發作者與程式碼審閱者之間的討論。

所有審閱者都批准，Rose 簽入程式碼

在此審查周期之後，審查者將程式碼標記為 OK，然後 Rose 可以將程式碼簽入通用程式碼庫。

有些團隊制定了一些政策，允許開發人員在實際審查完成之前簽入程式碼。這通常是針對一些微小的變化，以允許非同步審查和加快開發速度。

我描述的所有步驟都是 Microsoft 典型程式碼審查生命周期的一部分，並由所有團隊執行。根據團隊的政策，團隊對每個步驟的要求都會更加嚴格。

並非所有團隊都一樣

可以想像，微軟有 60,000 名工程師和非常多的團隊，並非都按統一標準來操作。Microsoft 的某些團隊可能在程式碼檢查生命周期中需要其他步驟或工具。我想簡要介紹一下一些團隊添加到程式碼審查過程中的一些額外步驟。

包含測試結果的程式碼審查

您最想要的功能可能是通過「自動檢測」的錯誤程式碼來節省時間。我的意思是，如果您可以運行自動化測試並意識到程式碼無法按預期工作，那麼這就是您應該做的：在審查之前運行測試。

這就是為什麼有些團隊要求在每次程式碼審查時都提交測試結果的原因。這樣就不會有人會忘記運行單元測試了。而且它可以確保在給定的程式碼更改下測試實際上已經運行並通過。

其他團隊甚至更進一步，以某種方式配置了程式碼審查工具：開發人員提交的每個程式碼審查都會觸發構建。該版本包含該確切的更改，並且還啟動了一系列自動化測試。這個構建和這些測試的結果將附加到程式碼審查中。通過這種方式進行配置，可以確保已使用公共程式碼庫中的最新程式碼對程式碼更改進行了測試。

包含用戶介面的程式碼審查

如果更改影響到用戶介面，則要求開發人員提交螢幕截圖也是一個好主意。這樣，程式碼審閱者可以在不運行程式碼的情況下看到程式碼更改的影響。其次，在自己的電腦上運行程式碼時，程式碼審閱者可以發現差異。

包括靜態分析的程式碼審查

靜態分析工具就程式碼樣式問題而言，可以為程式碼審閱者節省大量時間。Microsoft 的某些團隊將自動化的靜態和動態分析工具用作專用的機器人審閱者。這些機器人在程式碼樣式和其他靜態問題上給出評論。因此，可以騰出時間讓人工程式碼審閱者執行更多有趣的任務。

Microsoft 的程式碼審查工具

多年來，Microsoft 進行程式碼審查的事實上的標準之一是內部工具 CodeFlow。這是一個複雜的程式碼審查工具，可支援開發人員並指導他們完成程式碼審查的所有步驟。CodeFlow 在程式碼準備過程中提供幫助，自動通知審閱者，並具有豐富的評論和討論功能。

您可以在下面的螢幕截圖中看到，CodeFlow 是一個重 UI 工具，非常類似於 Word 或 PowerPoint。

CodeFlow 的介面說明

如果需要，可以跳過此步驟，如果感興趣，我將帶您瀏覽 CodeFlow 的介面。查看螢幕截圖，在左側 (A)，您會看到所有受影響的文檔。

同樣在左側，您會看到 (B) 分配給該本次審查的審閱者列表及其狀態（例如，已簽署或待審核）。活動文檔顯示在編輯器 (C) 中。在底部，您可以看到 (D) 所有文檔的注釋列表。

另一方面，在活動文檔 (F) 中只有一個注釋。此注釋與程式碼的具體部分（即一行中的一個單詞）相關。最後，在頂部，您將看到程式碼審查的總體狀態，在截圖中是完成狀態。之前的數字表示不同的修訂版本。在此審查中，有五個修訂。

注釋功能

CodeFlow 最好的功能之一就是它的注釋功能。

程式碼審閱者可以非常精確地選擇她要評論的程式碼部分。例如，審閱者甚至可以僅突出顯示一行中的一個或兩個字元，而不是突出顯示整行。然後，審閱者可以對該選擇附加評論。

該評論會發送給程式碼作者或其他審閱者，並且可以圍繞該評論發起對話。

評論功能

這種評論功能感覺就像在諸如 Twitter 或 Facebook 之類的社交媒體平台上評論。因此，CodeFlow 中的評論體驗非常自然，可以進行豐富的對話和討論。另一個不錯的好處是可以為每個注釋執行緒分配狀態。狀態可以是「無法解決」，「已解決」或「未解決」。

程式碼審查修訂之間的比較

一個有用的功能是可以選擇兩個不同的程式碼審查版本，並比較兩者之間的差異。這意味著您可以準確地看到程式碼作者在一個程式碼審查修訂版和另一個程式碼審查修訂版之間進行了哪些更改。跟蹤審核進度非常方便。

程式碼審查分析工具

在 Microsoft，開發人員花費大量時間進行程式碼審查。為確保這些時間花得有價值，Microsoft 擁有自己的程式碼審查分析平台。

該平台存儲所有程式碼檢查數據，從正在檢查的程式碼開始，到程式碼檢查中涉及的開發人員，再到開發人員的所有注釋。甚至可以追溯到每個修訂的程式碼更改。

這些程式碼審查數據是 Microsoft 對程式碼審查進行一些實證研究的基礎。許多產品團隊還使用它來跟蹤他們的生產率並了解他們自己的程式碼審查實踐。另外，我在此部落格文章系列中分享的許多關於 Microsoft 程式碼審查的見解都來自對該程式碼審查數據的研究和分析。

Micorsoft 程式碼審查的未來

隨著 Micorsoft 參與和收購 GitHub，一些變化是不可避免的。例如，Microsoft 已經廣泛採用 Git 作為源程式碼版本管理工具。同時，在 Microsoft，以 pull requests 形式進行的程式碼審查正在增加。