在Dr.Michaela Greiler的 How Code Reviews at Microsoft一文中提到，微軟有140000名員工，其中44%員工是工程師。這意味著，有超過6000名的工程師同時在同一個程式碼庫上開發Office、Visual Studio、Windows等產品。
想要確保不同子團隊開發的程式碼能完美協作，並不是一件易事。 那麼，如此大的工程師規模下，微軟到底是如何確保程式碼質量的呢？秘密在於程式碼評審！
微軟針對900多名開發人員的調查研究表明，有36%的開發人員表示他們一天回進行多次程式碼評審。以天為單位和以周為單位的開發人員分別佔比39%和12%，僅有13%的開發人員一週內未進行任何程式碼評審。
（圖片源自微軟調查報告）
程式碼評審是指在軟體開發過程中，對編寫的程式碼進行系統檢查和評估的過程。這是一種質量控制方法，旨在發現程式碼中的潛在Bug。 由此可見，程式碼評審起到了不可忽視的重要作用，從而確保程式碼可以在如此大規模的開發人員內實現順暢的協作。
一、是什麼絆住了你的程式碼評審？
程式碼評審有著諸多好處，如提高程式碼質量、發現程式碼中的缺陷、知識轉移等。程式碼評審的步驟看似很簡單，只需要“提交-修改-完善”，但實際過程往往會發生一些預期之外的事情，而這些事情則會降低整個程式碼評審的積極性甚至可能影響團隊的工作效率。
- 評審時間過長
《軟體工程通史》的作者卡珀斯·瓊斯（Capers Jones）分析了超過12000個軟體開發專案， 從實驗分析結果看，一般的程式碼評審速度約是一小時150行原始碼。但對於一些關鍵的軟體（例如安全關鍵系統的嵌入式軟體）來說，一小時審查數百行原始碼的審查速度太快，可能無法找到其中的問題。
我們不難看出，雖然程式碼評審對於發現潛在Bug起到了重要的作用，但也需要投入大量的時間，像業務需求不穩定、時間要求緊迫的專案，就難以進行程式碼評審。
- 評審效果難以衡量
程式碼評審的好處通常在長期和多次的實踐中才能顯示出來。透過程式碼評審，團隊成員可以學習和應用更好的編碼技巧和設計原則，從而提高自身的編碼能力。這種個人和團隊的成長需要時間和經驗的積累，因此，程式碼評審的效果在短期內可能不容易觀察到。
正是這些原因， 導致不少開發人員的程式碼會出現“管他有幾個Bug，能跑就行”的現象。長此以往，就會出現“屎山程式碼”導致可讀性差、可維護性差等情況。
二、DevOps平臺在程式碼評審中的作用
程式碼評審並不是浪費時間，程式碼評審一般可以找到並消除約65%的Bug，最高可以到85%。為了解決絆住程式碼評審的困難，越來越多的團隊開始採用DevOps平臺來輔助程式碼評審，DevOps平臺提供了一種整合和協作的環境，使得程式碼評審過程更加高效。
- 程式碼視覺化和協作
程式碼倉庫透過版本控制系統（如Git）管理程式碼的不同版本和變更歷史。程式碼評審可以針對特定的程式碼版本進行，透過對比不同版本之間的變更，開發人員可以更好地理解程式碼的演變過程和改動內容。同時，程式碼倉庫提供了一個協作平臺，團隊成員可以在同一個程式碼庫中/共同開發和維護程式碼。
- 使用程式碼靜態分析工具
靜態程式碼分析是一種在不執行程式碼的情況下對程式碼進行測試的方法，開發人員可以透過DevOps平臺管理SonarQube等靜態程式碼分析工具，自動檢測潛在的程式碼Bug，如空指標引用、未使用的變數等。
- 納入CI/CD過程
我們可以將程式碼評審納入持續整合和持續交付過程。每當有新的程式碼提交時，自動觸發構建、測試和評審流程。這樣可以及早發現問題，並確保高質量的程式碼被納入主幹分支。
- 資料分析和報告
DevOps平臺可以收集和分析程式碼評審的資料，提供有關程式碼質量和審查效率的指標和報告。這些資料可以幫助團隊瞭解程式碼評審的效果，並進行持續改進。例如，透過分析程式碼評審的結果和Bug的修復時間，團隊可以識別程式碼質量問題的瓶頸，並採取相應的措施進行改進。
三、寫在最後
一個成熟的團隊中，程式碼評審是整個研發流程中不可或缺的一步。我們注重程式碼審查的前提是一定要注重程式碼規範，統一的程式碼規範才有助於專案研發有效推進。
在此分享一下，禪道團隊的程式碼規範原則：
- 是否是駝峰還是匈牙利方法不重要，重要的是執行；
- 最重要的是命名，與其絞盡腦汁寫註釋，不如想象如何命名；
- 好的版式易於閱讀，學會用換行和註釋做程式碼片段區隔；
- 註釋最重要是正確，一定要和程式碼保持同步。
透過上文，我們不難看出，DevOps在程式碼評審方面發揮著積極作用，能夠提高程式碼評審的效率。 禪道積極響應市場，推出了 禪道DevOps平臺版，這不僅僅打通了從產品、需求、專案到開發、測試、運維環節，還具有加快交付速度、提高交付質量、減少團隊摩擦、實現快速反饋等優勢。
“冰凍三尺非一日之寒，滴水石穿非一日之功”。雖然程式碼評審會耗費團隊不少的精力和時間，但我們不能低估它的長期價值，堅持下去必然會讓整個程式碼庫、系統甚至團隊更加健康。