全球最大的軟體公司之一微軟擁有約 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 程式碼審查週期的正常程序，被所有團隊執行，根據團隊不同而略有出入。
如果開發者把使用者交互介面也改了，那 TA 最好截個屏給別人看下。這樣審查者就省的跑程式碼了，直接看圖片就行，審查者也可以方便檢查因運行環境不同而產生的差異。
靜態分析對規範程式碼樣式來說尤其有效。微軟的一些團隊使用自動化的靜態和動態分析工具作為專用的機器人評審員。這些機器人評論程式碼樣式和其他靜態問題。這樣就能騰出時間讓人工程式碼審閱者執行更有趣的任務。
多年來，微軟實際上的程式碼審查標準之一是一個名為 Codeflow 的內部工具。這是一個複雜的程式碼審查工具，它支持開發人員並指導他們完成程式碼審查的所有步驟。
隨著 Micorosft 的參與和對 GitHub 的收購，改變是不可避免的。例如，在 Microsof t 中廣泛採用 git 作為源程式碼管理工具，就可以看出這種變化。但是，這也意味著在微軟，以「pull request」的形式進行的程式碼審查正在上升。