全球最大的軟件公司之一微軟擁有約140,000名員工，其中大約44％，即超過60,000名員工，是工程師。

Office、Visual Studio或Windows等幾種產品，都是由數千名同時在同一代碼庫上工作的工程師開發的。確保由不同子團隊開發的代碼完美地協同工作是一件非常重要的任務。

那么你想過么，如此大的工程師規模下，微軟是如何確保代碼質量的呢？

微軟的法寶在于：完整的代碼評審機制！

微軟代碼評審是一種被廣泛采用的工程實踐。成千上萬的工程師認為這是一個偉大的最佳實踐。大多數高績效團隊花費大量時間進行代碼評審。

那么，微軟的代碼評審究竟是一種怎樣的機制呢？今天，文摘菌就帶你來一探究竟。

調研微軟的代碼評審

在微軟代碼評審的大規模研究中，我們采訪、觀察并調查了900多名開發人員。

我們的目的是了解如何在微軟完成代碼評審。我們想知道，在進行代碼評審的時候，開發人員面臨哪些陷阱，以及他們為克服這些挑戰而開發的最佳實踐。

您可以從微軟的代碼評審實踐中學到什么？

大多數經驗教訓對于小型或大型團隊組織都很有價值。如果您的團隊尚未進行代碼評審，我會向您展示該實踐的好處。如果您的團隊已經有了代碼評審機制，您可以將您的實踐與微軟的代碼評審實踐進行比較。

微軟工程師多久進行一次代碼審查？

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

這意味著，微軟的開發人員將大量時間花在代碼評審上。因此，確保有效使用這段時間非常重要。

代碼評審提供哪些好處？

代碼評審的好處

代碼評審最重要的好處是，提高代碼質量并找到代碼中的缺陷，另一個重要好處是知識轉移。

知識轉移意味著，審核彼此代碼的團隊成員熟悉代碼庫的大部分內容。但是，這也意味著代碼評審最好在團隊內部實施。另一個優點是，新的團隊成員和初級開發人員可以在審閱或獲得反饋的同時學習和提高他們的編碼技能。

如果開發人員在代碼評審期間討論替代解決方案，它不僅可以改善代碼庫，還可以為所有相關人員提供學習機會。因此，學習、指導和自我改進是代碼評審之所以被認為是微軟的一種有益實踐的主要原因。

開發人員通常如何進行代碼評審？

代碼審查可以通過多種方式執行。有時，可以很不正式， 比如一位開發人員走到另一位開發人員的桌邊一起看一些代碼。其他時候，團隊一起審核代碼。但是，您在微軟的代碼審查中遇到的最可能的情況是，代碼評審是在借助工具的幫助下完成的。

代碼評審的工具有很多種。在微軟，團隊可以自由選擇他們的工具。 至2016年，89％的開發人員表示使用CodeFlow代碼評審工具。稍后我將解釋更多有關此代碼評審工具的信息。從那時起，隨著Git的興起，工具領域發生了變化。

現在，讓我們考慮一個典型的代碼評審案例： 微軟的開發人員Rose剛剛完成了一個功能，現在想要得到她同行的反饋。

Rose如何在微軟開始代碼審查？

Rose首先要為代碼評審做準備。這一步包括打開代碼評審工具，允許她預覽代碼更改。代碼評審工具可以執行差異化對比任務，幫助羅斯確切了解她做了哪些更改。

在仔細審查了這些變化之后，她標記了一些備注，告訴評審人她做了什么以及為什么這樣做。備注說明有助于審閱者了解代碼更改的目的和動機。至此，代碼已準備好可以發送給審閱者了。

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

許多經驗豐富的開發人員都知道應該選誰作為代碼審閱者。然而，對于團隊中的新人或新的工作領域，選擇可能會更棘手。如果Rose不知道她應該添加誰，她會查看團隊規定或詢問她的同事。她還可以使用代碼評審工具的推薦功能，該工具可以根據代碼庫的經驗和知識幫助選擇審閱者。

誰是相關審閱者？

Rose選擇她認為可以為這段代碼貢獻知識的審閱者。審閱者通常是其他開發人員，但也可以包括其他利益相關者，例如開發人員工程師，UI專家或經理。一些評審員被選是基于他們的專業知識，其他評審員被選是為了讓他們能隨了解即將發生的變化。

代碼評審的一般步驟

Rose要求她的同行反饋

一旦選中每個人，Rose就會發出代碼評審。代碼評審工具會自動發送創建評審的通知到每個人。通知對象不僅包括所有審閱者，也會包括其他人員，例如相關團隊的經理或產品經理。這些通知允許他們的信息保持同步，即使他們不需要執行評審。

接受反饋是個迭代過程

Rose的同事們有時間就會審查代碼。每個審查者都能評注代碼，完事后把代碼發回Rose，Rose可以據此修改代碼。

審查者通常關注的點包括：代碼有bug嗎？代碼結構有問題嗎？代碼有拼寫錯誤、少個冒號之類的小毛病嗎？不是所有的評注都重要，但是有幾個小技巧可用來提升代碼評注。

Rose準備新版本的代碼

Rose根據評注修改代碼。如果有的地方弄錯了或有爭議，Rose可能直接去跟審查者面談，或者通過審查工具交流會更私人化一點。

不管怎樣，一旦Rose根據反饋完成了代碼修改，她可以發一份新版本的代碼給審查者，這份代碼叫修訂版。

若有必要，她還會收到反饋。這個循環視情況而定會持續好幾輪，一般的小代碼審查一次即可，復雜的代碼可能得審查多輪。

這樣的工作是很常見的，還可能在作者和審查者之間擦出思維的火花。

所有的審查者都批準，Rose登記代碼

完事之后，審查者標記代碼為okay，Rose終于可以把代碼補充到公共代碼庫了。有些團隊會允許開發者在審查結束前就把代碼上傳到代碼庫。這種情況通常在代碼只需小修小改的時候發生，這樣可以異步審查并加速開發。

上面我說的所有步驟都是Microsoft代碼審查周期的常規操作，被所有團隊執行，根據團隊不同而略有出入。

并非所有團隊都一樣

如你所想，事情并非一成不變。Microsoft的一些團隊會有些額外步驟或工具助力代碼審查。我會簡單介紹這些額外步驟。

包含測試結果的代碼審查

可能你最不想做的事情就是，審查那些代碼審查軟件就可以審查的代碼。所以你應該在審查之前先跑一遍測試。

一些團隊要求做代碼審查的時候把測試結果也一起上傳。這樣可以保證人人都測試一下。

其它團隊可能更加嚴格，每個審查者審查的時候都會觸發編譯，編譯和測試的結果都會被放在審查報告上。

涉及用戶交互界面的代碼審查

如果開發者把用戶交互界面也改了，那TA最好截個屏給別人看下。這樣審查者就省的跑代碼了，直接看圖片就行，審查者也可以方便檢查因運行環境不同而產生的差異。

包含靜態分析的代碼審查

靜態分析對規范代碼樣式來說尤其有效。微軟的一些團隊使用自動化的靜態和動態分析工具作為專用的機器人評審員。這些機器人評論代碼樣式和其他靜態問題。這樣就能騰出時間讓人工代碼審閱者執行更有趣的任務。

微軟的代碼審查工具

多年來，微軟實際上的代碼評審標準之一是一個名為codeflow的內部工具。這是一個復雜的代碼評審工具，它支持開發人員并指導他們完成代碼評審的所有步驟。

Codeflow幫助編寫代碼，自動通知審閱者，并具有豐富的注釋和討論功能。

codeflow是一個相當依賴UI的工具，很像Word或PowerPoint，如下面的截圖所示。

CodeFlow界面說明

看屏幕截圖，在左邊(A)你可以看到所有受影響的文件。

同樣在左邊，您可以看到(B)分配給評審的審核員名單以及他們的狀態(例如，已簽署或待決)?；顒游臋n顯示在編輯器(C)中。在底部，您可以看到(D)所有文檔的注釋列表。

另一方面，在活動文檔(F)中只有一個注釋。此注釋連接到代碼的具體部分(即一行中的一個單詞)。最后，在頂部，您可以看到代碼評審的總體狀態。在這種情況下，已經完成。之前的數字表明了不同的修正。在這次審查中，進行了五次修訂。

評注功能

Codeflow最優秀的特性之一是它的評論功能。代碼審閱者可以非常精確地選擇她想要評論的代碼的部分。例如，審閱者甚至可以在一行中高亮顯示一個或兩個字符，而不是突出顯示整個行。然后，審閱者可以將評論附加到該選擇。

將此注釋通知代碼作者或其他審閱者，并可以圍繞此注釋以線程的形式啟動會話。

討論功能

這種評論功能就像在Twitter或Facebook等社交媒體平臺上發表評論。因此，Codeflow的評論體驗非常自然，人們可以進行豐富的對話和討論。另一個不錯的好處是可以為這些評論線程中的每一個指定一個狀態。例如，狀態可以是“不會修復”、“已解決”或“打開”。

代碼評審修訂的比較

你也可以選擇代碼評審的兩個不同版本，并比較兩者之間的差異。這意味著您可以準確地看到代碼評審作者在一個代碼評審修訂版和另一個代碼評審修訂版之間執行了哪些更改。這方便了跟蹤審查的進展。

代碼評審分析工具

開發人員花費大量時間在Microsoft執行代碼評審。為了確保這段時間得到充分利用，Microsoft擁有自己的代碼評審分析平臺。

該平臺存儲從代碼評審開始的所有代碼評審數據，參與代碼評審的開發人員，以及開發人員的所有評論。甚至可以追溯每次修訂的代碼更改。

這些代碼評審數據是Microsoft對代碼評審進行多項實證研究的基礎。許多產品團隊也使用它來理解他們自己的代碼評審實踐。

微軟代碼評審的未來

隨著Micorosft的參與和對GitHub的收購，改變是不可避免的。例如，在Microsoft中廣泛采用git作為源代碼管理工具，就可以看出這種變化。但是，這也意味著在微軟，以”pull request”的形式進行的代碼評審正在上升。