微軟是如何作 Code Review 的

本文由知乎網友漫慢忙翻譯自 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 形式進行的代碼審查正在增長。