【為什麼我們要挑選這篇文章】微軟擁有上萬名工程師，讓不同團隊開發的程式能順利進行至關重要，他們的秘密武器就是一套完善的程式碼審查機制。審查機制具體如何運作？本篇文章為採訪過 900 多位微軟開發人員的結果，將介紹、分析微軟程式碼審查的運作模式。（責任編輯：方禹涵）
「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息 快將你的履歷自傳寄至 jobs@fusionmedium.com」
全球最大的軟體公司之一微軟擁有約 140,000 名員工，其中大約 44％，即超過 60,000 名員工，是工程師。
Office、Visual Studio 或 Windows 等幾種產品，都是由數千名同時在同一程式碼庫上工作的工程師開發的。確保由不同子團隊開發的程式碼完美地協同工作是一件非常重要的任務。
那麼你想過嗎，如此大的工程師規模下，微軟是如何確保程式碼品質的呢？
微軟法寶在於「完整的程式碼審查機制」！
微軟程式碼審查是一種被廣泛採用的工程實踐。成千上萬的工程師認為這是一個偉大的最佳實踐。大多數高績效團隊花費大量時間進行程式碼審查。
那麼，微軟的程式碼審查究竟是一種怎樣的機制呢？今天，文摘菌（本文作者）就帶你來一探究竟。
研究微軟的程式碼審查
在微軟程式碼審查的大規模研究中，我們採訪、觀察並調查了 900 多名開發人員。
我們的目的是了解如何在微軟完成程式碼審查。我們想知道，在進行程式碼審查的時候，開發人員面臨哪些陷阱，以及他們為克服這些挑戰而開發的最佳實踐。
大多數經驗教訓對於小型或大型團隊組織都很有價值。如果您的團隊尚未進行程式碼審查，我會向您展示該實踐的好處。如果您的團隊已經有了程式碼審查機制，您可以將您的實踐與微軟的程式碼審查實踐進行比較。
微軟工程師多久進行一次程式碼審查？ 在這項研究中，36％ 的開發人員表示他們每天進行多次程式碼審查。另有 39％ 的開發人員表示，他們每天至少進行一次程式碼審查。12％ 的人每週多次進行程式碼審查，只有 13％的人表示過去一週他們沒有進行程式碼審查。
這意味著， 微軟的開發人員將大量時間花在程式碼審查上 。因此，確保有效使用這段時間非常重要。
程式碼審查提供哪些好處？
程式碼審查的好處 程式碼審查最重要的好處是，提高程式碼品質並找到程式碼中的缺陷，另一個重要好處是知識轉移 。
「知識轉移」意味著，審核彼此程式碼的團隊成員熟悉程式碼庫的大部分內容。但是，這也意味著程式碼審查最好在團隊內部實施。另一個優點是，新的團隊成員和初級開發人員可以在審閱或獲得反饋的同時學習和提高他們的編碼技能。
如果開發人員在程式碼審查期間討論替代解決方案，它不僅可以改善程式碼庫，還可以為所有相關人員提供學習機會。因此，學習、指導和自我改進是程式碼審查之所以被認為是微軟的一種有益實踐的主要原因。
開發人員通常如何進行程式碼審查？
程式碼審查可以通過多種方式執行。有時，可以很不正式， 比如一位開發人員走到另一位開發人員的桌邊一起看一些程式碼。其他時候，團隊一起審核程式碼。但是，您在微軟的程式碼審查中遇到的最可能的情況是：程式碼審查是在藉助工具的幫助下完成的。
程式碼審查的工具有很多種。在微軟，團隊可以自由選擇他們的工具。至 2016 年， 89％ 的開發人員表示使用 CodeFlow 程式碼審查工具。稍後我將解釋更多有關此程式碼審查工具的信息。從那時起，隨著 Git 的興起，工具領域發生了變化。
現在，讓我們考慮一個典型的程式碼審查案例： 微軟的開發人員 Rose 剛剛完成了一個功能，現在想要得到她同行的反饋。
開發人員 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 的收購，改變是不可避免的。例如，在 Microsof t 中廣泛採用 git 作為源程式碼管理工具，就可以看出這種變化。但是，這也意味著在微軟，以「pull request」的形式進行的程式碼審查正在上升。
（本文經合作夥伴 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈我们走访了 900 名微软员工，为你揭秘全球最大软件公司的代码评审机制 〉。首圖來源：Wikipedia 。）
延伸閱讀
【內附程式碼】工程師技能大全：如何用 Python 寫出所有的演算法？ GitHub 最強 AI 數學解題神器！拍照上傳秒給答案，連微積分都難不倒他 GitHub 史上最大改版：能讓程式碼在網頁上運行的 GitHub Actions
我們正在找夥伴！
2019 年我們的團隊正在大舉擴張，需要你的加入跟我們一起找出台灣創新原動力！
我們正在徵
《採訪社群編輯》、《助理編輯》 ，詳細職缺與應徵辦法
請點我
Linkedin Recuriter 瓶頸：個性化需求
可以說，
