我們走訪了900名微軟員工，為你揭祕全球最大軟體公司的程式碼評審機制

大資料文摘出品

來源：michaelagreiler

編譯：倪倪、錢天培、毅航

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

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

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

微軟的法寶在於：完整的程式碼評審機制！

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

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

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

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

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

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

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

程式碼評審的好處

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

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

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

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

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

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

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

在仔細審查了這些變化之後，她標記了一些備註，告訴評審人她做了什麼以及為什麼這樣做。備註說明有助於審閱者瞭解程式碼更改的目的和動機。至此，程式碼已準備好可以傳送給審閱者了。

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

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

程式碼評審的一般步驟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Codeflow幫助編寫程式碼，自動通知審閱者，並具有豐富的註釋和討論功能。

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

CodeFlow截圖 (2016)

CodeFlow介面說明

看螢幕截圖，在左邊(A)你可以看到所有受影響的檔案。

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

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

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

將此註釋通知程式碼作者或其他審閱者，並可以圍繞此註釋以執行緒的形式啟動會話。

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

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

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

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

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

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

相關報導：

https://www.michaelagreiler.com/code-reviews-at-microsoft-how-to-code-review-at-a-large-software-company/