Code Review，在當代的軟件開發中占有重要的一環。雖然國內各大主流公司都已經參照國外同行設立了比較嚴格的Code Review機制，但是還是有好多大型軟件公司以及中小型軟件公司還未推行這一重要制度。那么在美國的科技企業中，Code Review推行的怎么樣呢？本文就帶大家來進行一個全面的了解。本文將主要探討如下幾個部分，在公司內部推行Code Review的必要性，以美國某大型公司的內部工具進行具體Code Review流程講解，作為CodeReview的雙方應該在這一過程中注意什么。

Code Review的必要性

在一次完整的代碼提交過程中，我們需要經過以下步驟

• 從主代碼庫中Check out出自己的分支

• 在自己的分支中進行代碼修改

• 編寫測試代碼確保自己新增的代碼邏輯不會破壞現有代碼，以及新增代碼被測試用例覆蓋到

• 如果測試用例檢測出代碼邏輯問題，對代碼進行修改

• 提交Code Review

• 在獲得了審閱者通過后，并且通過了所有自動化測試用例，才可以將代碼放置到生產環境代碼庫中 由此我們可以看出，Code Review是將代碼提交代碼庫中的最終也是最重要的環節。沒有這一環的保證，代碼庫中將充斥著大量低質量，甚至是錯誤的代碼。

相對于國內公司大部分公司并沒有全面推行Code Review，在美國，基本所有的非外包科技類公司都對這一環節進行了很好的推行，幾乎每個開發團隊每天都需要進行Code Review。以作者的了解，像Google、微軟這類大型公司往往對Code Review的把控比較嚴格，至少需要兩個同事通過，你的代碼才可以提交到最終生產環境代碼庫中。如果某些修改的代碼比較大，可能需要組里級別比較高的成員——比如資深工程師甚至是工程經理，通過才可以。有的修改如果牽涉到其他組的代碼，還需要對應項目組的工程師通過才可以。那么既然Code Review是這么一件繁瑣的事情，為什么各個公司還是不遺余力的推行呢。作者認為主要是以下方面使得這一環節在現代軟件開發中十分必要。

• 有效的保證了代碼風格的一致性 團隊不需要再浪費時間去討論個人喜好的代碼風格，比如是用兩個空格縮進還是四個空格，一行代碼多長需要換行等等。編寫代碼的工程師只需要參照已有代碼庫中的編碼風格即可，包括統一的命名規則，比如文件名和變量名，相似風格的代碼注釋。這一點其實對小公司更為重要，小公司相對大公司有更大的人員流動，從而更有可能出現各種風格的代碼。另外，大公司內部工具相對完善，比如都會裝有代碼風格檢查的工具，使得代碼格式一致，而小公司可能需要更為嚴格的代碼審查來保證這一點。

• 預防可能出現的Bug 編寫程序并不是簡單的體力勞動，那么在代碼的創作過程中工程師難免會出現一些考慮不周的情況，比如某些未考慮到的邊界情況，可能會造成代碼在某些情況下崩潰，又或者是工程師在某些疲勞狀態下寫出的一些顯而易見的錯誤。Code Review就是三個臭皮匠頂個諸葛亮的最佳詮釋，在這一過程中發現代碼中的錯誤。

• 相互討論促進和諧友好的工程師氛圍以及對代碼庫更完備的理解 在Code Review時，工程師之間并沒有等級之分，即使你作為一個初級工程師，也可以給資深工程師審閱代碼。作為被Review者，因為會和進行審閱的工程師不斷溝通，從而對自己做的這一問題有了更深入的了解。有時，也會從資深工程師給出的代碼評論中學到一些之前并不了解或者并不重視的技術細節，從而提高個人水平。而作為進行審閱的工程師，或許之前并沒有接觸過你代碼的業務邏輯，通過審閱他也對這一領域有了了解。這一點非常重要，因為這可以幫助他在線上代碼出現問題時，進行有效的排查。因為作者所在的公司每周一進行生產代碼部署，所以我就會在Oncall（美國科技公司讓工程師進行輪崗，以便線上代碼出現問題時可以快速介入進行問題排查）前一周就會選擇性對某些比較大的PR（Pull Request，指工程師將一系列文件修改提交到代碼庫中）進行Review，做到心中有數，一旦出現問題，可以找到對應的責任人對問題進行快速修復。

Code Review的流程

我們以某公司內部的Code Review工具來看看一次完整的Code Review過程是怎么樣的。在該工具中A處表示這一次提交的代碼所涉及到的全部被修改的文件。B處說明了這次代碼修改的作者是誰(author)，哪些人是必須作為審閱者來審閱代碼的（required），哪些審閱者是可選的（optional），對應審閱者是否通過代碼，如果審閱者通過了你的代碼，他的狀態就會變成一個對勾符號。如果被標記為required的審閱者不通過，那么你的代碼是不能進行最后的提交的。C表示作者做出的修改，圖中紅色部分為刪除的代碼，綠色部分為新增加的代碼。D處是所有評論的概覽，通過概覽點擊可以直接定位到評論對應的代碼部分。E處是代碼修改的次數，在作者第一次提交時被標記為1，當審閱者針對第一輪代碼提出意見后，作者會對代碼某些部分作出修改后再提交審閱。而每一次作者提交代碼，上面對應的數字都會加1。當審閱者通過你的代碼，你將代碼提交到代碼庫中以后，那么這次Code Review也宣告結束，在數字旁邊會標注完成（Completed）。F處是作者和審閱者交換意見的地方，比如審閱者Trevor提出了問題，那么作者Christian在其下方進行回復，如果Trevor覺得作者說的合理，那么審閱者就將評論狀態設置為關閉（Closed），表示其對這一部分的異議已經消除。這一過程也是區分一個工程師是新手還是老手的過程，一個菜鳥工程師往往需要多達10幾輪的Code Review，而一個老手往往在幾輪之后就可以順利將代碼提交。

那么作為被review者和review者需要在Code Review中怎么做呢？

被Review者

工程師最好提前針對這次提交的代碼設計跟進行Code Review的工程師進行討論，確保自己的設計和思路沒有偏離方向，否則后續需要進行好多修改。

在提交Code Review時，最好有一些文字進行解釋，比如提交的代碼解決了什么問題或者增加了什么功能，為了這些改進自己是怎么進行修改的，以及自己是怎么進行測試的。這樣可以方便其他一些工程師主動參與進來，提出意見。

在自己的代碼中盡量避免出現一些較為低級的，明顯需要修改的代碼。比如參照已有代碼格式，命名等，確保自己的代碼風格和已有代碼是完全兼容的。

要對自己的代碼有責任心，要確保自己了解做出的每一處修改，而不僅僅只是為了通過Code Review。不要過分依賴其他review代碼的工程師，認為他們可以找出每一處潛在bug。

Review者進行Review的工程師在review別人代碼時，盡量看到好的一面，這一點在給新人進行review時尤其重要。在給新人review時也是傳授方法的好時候。授人以魚不如授人以漁，當新人成長起來可以獨擋一面，同時也減輕了你的工作量。

進行評論時要注意語氣，盡量使用一些語氣助詞和Emoji符號表情，比如能否請你把XX改成XX？這里是不是用XX方法比較好。這樣也更讓對方易于接受。

積極主動參與Code Review可以讓你對項目代碼熟悉程度比較均衡，不會出現某個地方完全不了解的情況。而作為新人工程師，更需要積極參與Code Review，尤其盡量至少對每個組員的工作都進行review，這樣也可以更為快速的了解組里其他工程師正在做的工作。

總結

本文通過美國某公司內部Code Review工具實例介紹了一次完整的Code Review是怎么樣的，并對Code Review雙方給出了建議。希望所在公司還沒有推行Code Review機制的小伙伴能多多諫言推行，從而減少一些低質量代碼帶來的苦惱。

PS. 如果覺得文章還不錯，歡迎點贊/分享/轉發本文。如果你想加入號主的討論群，可以在公眾號的關于我們->技術討論群中找到微信群組。

總結

以上是生活随笔為你收集整理的听我的！美国科技公司这样做Code Review的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。