原文地址：https://www.zhihu.com/question/41089988
回答人：騰訊Bugly（ 這個名字有點意思）
分享一下鵝廠團隊的Code Review經驗，希望對大家有所幫助。
======
精神哥最近和團隊中的開發同學聊天，看到很多開發同學對代碼技能的提升都是有訴求的，只不過快速的業務節奏沒有給他們太多停留的時間，在這種情況下如何給團隊營造濃厚的工程師交流氛圍呢？
方法有多種，目前最被認可或運用的方法莫過於CodeReview活動了。
那麼 CodeReview到底能給團隊帶來什麼？什麼樣的團隊需要進行CodeReview活動？如何有效開展CodeReview活動？用哪種方式會比較好呢？
筆者爲了接地氣地研究這個實踐，特選擇了“手機管家高權限應用組”作爲試點團隊進行活動開展，這是一個對CodeReview活動非常認同並且願意持續改進的團隊，經過一年的運作，該團隊CodeReview活動運作成效顯著。
接下來筆者就根據試點經驗，總結一下對CodeReview這個實踐的看法和思考，希望能對想要或正在進行CodeReview活動的團隊提供借鑑作用。
一、CodeReview到底能給團隊帶來什麼？
通過參與實戰和團隊成員討論思考，我們認爲CodeReview最終的作用將歸到促進工程師日常代碼交流和人員的成長上面來，與此同時作爲輔助手段來對產品質量進行把關。
但一般來說，很多團隊在CodeReview前期重點會是找問題（代碼規範、潛在缺陷、BUG，代碼設計等等），而後期隨着問題的逐漸減少和習慣的逐步養成，工程師交流文化的營造將轉化成重點，中期當有大批新人加入時，問題找茬將又上升爲重點，如此復始。
總結一下，大多數情況下，找問題會是CodeReview活動啓動的初衷，但越到後期它更大的意義將演變成工程師交流土壤的培育和人員成長的促進。
二、什麼樣的團隊需要進行CodeReview活動？
CodeReview作爲業界公認的最佳實踐，如果每個團隊都能運用起來，固然是最好的，但是由於這項活動跟“人”這個因素密切掛鉤，所以，它是否能有效運作跟團隊狀態、技術信仰和領導者訴求等都有莫大關係。今天，筆者想分享下個人在“到底什麼樣的團隊需要”和“什麼樣的團隊暫時不適合”這方面的思考。這裏歡迎大家更多的交流討論。
從代碼質量提升的角度上看，以下類型的團隊，筆者建議把CodeReview活動有效運作起來：
-
技術驅動型團隊：一般涉及系統底層邏輯較多，功能路徑難以被測試覆蓋，而產品質量問題很多時候是致命的，所以這樣的團隊更多需要開發編碼的嚴謹性和相關代碼質量的保證活動。手機管家高權限應用組就屬於這一類型。
-
公共服務型團隊：一般服務於多個團隊，一旦出現質量問題影響範圍會比較廣，所以除了在測試方面加以把關外，通過CodeReview活動來提升開發質量是非常有必要的。
-
測試缺失型團隊：這樣的團隊由於缺乏測試環節，質量問題帶到線上的風險會很高，強烈建議在開發環節做好自檢工作。
-
新人密集型團隊：新人的代碼可讀性往往是比較差的，特別需要組織能及時給予糾正，幫助新人養成良好的編碼習慣。同時如果團隊產出的代碼可讀性較高時，新人也可以更快上手工作。
-
任何有主觀意願的團隊：這樣的團隊或領導者認同CodeReview的意義，或團隊成員對代碼質量提升有追求。
CodeReview活動跟人這個因素密切相關，從其帶有的這個主觀特點來說，筆者認爲以下類型的團隊暫時不適合開展CodeReview活動：
-
不認同型團隊：即領導和團隊骨幹都不認同CodeReview意義的團隊，這樣的團隊無論從推動還是堅持上都有很大挑戰。
-
疲於應付型團隊：這種團隊一般沒有建立必要的持續提升機制，每天淹沒在各種需求溝通實現變更和優化中，自然，代碼質量提升活動也很難被列入backlog。
-
創新型團隊：這種團隊的重要任務是要把產品快速推向市場進行價值驗證，所以在代碼編寫上要求足夠敏捷，代碼暫時的混亂完全可以接受。
綜上，筆者建議大家在考慮自身團隊是否要推行CodeReview時，可結合團隊實際狀態進行綜合考慮。但一般來說，如團隊主觀意願沒有問題，就可以大膽推行開展。
三、如何有效開展CodeReview活動？
要想在團隊內部有效運作CodeReview活動，必備四要素（如下圖）。如果您的團隊沒有把CodeReview活動有效開展下去或者正深受煩惱，這部分內容希望您仔細看看。
1、代碼規範：明確Coding規則如果一開始不定義好團隊Coding標準，那在檢視過程中就會存在兩種情況：一種是各種不同的意見很難快速達成一致，影響review效率，另外一種是團隊根本就不會重視代碼規範的檢視， 如果是前者還好，畢竟大家都還在關注什麼寫法是好的或對的這個問題，只要中途願意建立起Coding規則，問題就能很快解決。而筆者跟進過的一個團隊恰恰就出現了後者的情況：該團隊由於前期沒有明確Coding規則， 過程中大部分開發人員對規範類問題直接無視，CodeReview運作一段時間後代碼中依然存在命名不規範，可讀性較差等問題，直接影響了活動效果，這是我們非常不願意看到的。
當然也有團隊負責人說了，每天糾結於空格少了，行數字符多了等細節問題沒意義啊，不想浪費這個時間，因此我們不需要代碼規範。我個人不認同這個觀點，因爲代碼規範並不只包括空格和字符等約束緯度，還包括了註釋的要求，命名的規範，命名是否詞能達意，代碼結構安排等等影響代碼可讀性的因素， 如若這些方面連基本規則都沒有，那一定會出現之前說的那兩種情況（爭議太多 or 完全忽視），效果可想而知。所以你可以根據自己的看法或需求做一定的規則定製，但不能沒有Coding規則。
2、檢視指南：消除困惑和迷茫
檢視指南又名CodeReview-checklist。一個團隊並不是所有人都是老司機，有很多同學是沒有代碼review經驗的，他們往往不知道應該重點 check哪些點。
這個時候結合自身業務特點和團隊之前踩過的坑，制定一個checklist是非常必要的:
- 什麼寫法可能導致性能低下？
- 哪個接口要慎用？
- 哪些設計方式需要規避？
- 什麼習慣容易引發內存泄漏？
- 等等。。。
這樣可以讓經驗不足者在不知道要review什麼時，能有的放矢，過程中逐步積累起經驗。
以下是一個團隊建立起檢視指南前後，CodeReview發現問題數的變化，足見建立檢視指南的重要性。
當然也有人說，我的團隊代碼檢視都是讓資深骨幹做的，不存在不知道怎麼review的情況。
但是我想說，骨幹員工的時間畢竟很寶貴，他們也往往很忙碌，爲什麼不讓更多的成員一起來參與review工作呢，畢竟CodeReview不僅僅是找茬，也是代碼的交流和學習！
3、總結優化：透明問題，持續優化（非常重要）
我們看到很多團隊的CodeReview活動堅持不下來或逐步流於形式，其實最主要原因是過程中缺乏定期回顧和總結，從而不知道如何有效促進和幫助團隊更好運作。
爲了更好地促進這項活動，手機管家高權限應用組就專門成立了CodeReview組委會，這個組織每月都會對CodeReview運作狀況進行總結，分析問題，解決問題，持續優化，其最後的效果能在團隊內外均獲得較高的認同度，可以說總結優化這個環節起到了非常關鍵的作用。
4、激勵機制：激發主觀能動性
由於CodeReview本身跟人的經驗或者意識都有很大關係，很多時候我們會爲調動不起開發同學的積極性而煩惱，所以爲了讓大家更好的參與這個活動，我們一般都需要制定相應的激勵機制。也有人說了，如果是leader強制跟考覈掛鉤，那就不需要這個東東了，嗯，但換個角度看，跟考覈掛鉤難道不是另外一種“激勵”方式嗎？哈哈。。。
激勵機制的設立有很多種，一般來說，都是在定期回顧的基礎上根據CodeReview的實際情況對錶現積極的同學進行一定的禮品獎勵（選擇什麼禮品，要看組織的經濟狀況，哈哈）。
筆者跟進的團隊每月會從CodeReview提交次數和發現問題數等緯度進行質量之星選舉，禮品包括了書籍，公仔，徽章等等，效果不錯，做法供大家參考。
總之，代碼規範、檢視指南、總結優化和激勵機制這四個因素對成功運作CodeReview活動都非常關鍵，但每一項裏面的內容具體要如何定義，團隊在參考業界做法的基礎上可根據實際情況進行一定的定製。
四、CodeReview方式很多，用哪種會比較好呢？
目前業界運作CodeReview的方式有多種方式：強制&非強制、線上交流&線下會議、小片段&大模塊、事前&事後、高頻率&低頻率，等等……據瞭解，目前每種形態都有各自的市場，被不同的團隊運用着。
接下來筆者個人角度分析下各種形態的優缺點，供大家參考：
-
強制&非強制： 按照經驗，CodeReview啓動前期建議採用強制要求，否則很難有效開展起來。堅持一段時間待習慣養成後再考慮自由度。
-
小片段&大模塊：如果想要讓問題暴露更充分或降低review的難度，建議採用細粒度方式進行，即小片段提交小片段review。如果更關注全局設計和邏輯思路的學習和找茬，那麼可以用模塊方式統一review。但很多時候這兩種方式是可以結合運作的。
-
線上交流&線下會議： 如果想提高效率，建議採用線上方式進行交流，這裏要推薦公司的Code平臺，上面支持CodeReview的功能都已經比較齊全。如果更喜歡全員一起找茬的那種快感，那麼可以採用線下會議方式開展，但採用開會的方式，一般成本較高，可看團隊接受度。
-
事前&事後：這裏指的是發佈前還是發佈後。版本發佈後統一進行CodeReview的方式更多是一種代碼交流活動， 起不到代碼質量把關的作用。反之，如果在版本發佈前就對代碼進行CodeReview，就可以對質量問題起到很好的把關作用。這裏是時間和質量之間的權衡。
-
高頻率&低頻率：筆者建議的是把代碼交流放在每一天，所以頻率越高越好。具體根據團隊實際情況進行安排即可。
-
此外，也有團隊採用模塊owner把關質量的CodeReview方式，這種更多是從質量風險規避角度上考慮，在代碼提交前owner檢查是否有質量問題，確認沒有問題後方能發佈，有這方面需要的團隊也可以考慮這種方式。
最後組合一下，筆者個人推薦的CodeReview方式是強制+事前+小片段+線上交流+高頻率，同時，如果能結合線下的大模塊方式開展代碼交流活動，效果會更好，這個經驗來自手機管家高權限應用組的接地氣實踐。
但是，團隊狀態不一樣，選擇方式允許有差異，所以具體選用哪種方式組合，還是要由團隊自己作主。
五、結語總結
爲了讓這篇文章能給讀者帶來一定幫助，筆者反覆進行了review和相應的修改操作，且不論最終目的有沒有達到，至少態度和行爲上都已努力做到最好。
同樣，筆者認爲，開發編寫的Code, 要想讓別人更容易讀得懂，一定也需要review纔有可能達到目的。
所以，我們一起讓CodeReview活動這股清流飛起來吧~
更多精彩內容歡迎關注騰訊Bugly的微信公衆賬號：
http://weixin.qq.com/r/vkxZQYjES9U0rcwi9xms (二維碼自動識別)
騰訊Bugly是一款專爲移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上應用崩潰的情況以及解決方案。智能合併功能幫助開發同學把每天上報的數千條 Crash 根據根因合併分類，每日日報會列出影響用戶數最多的崩潰，精準定位功能幫助開發同學定位到出問題的代碼行，實時上報可以在發佈後快速的瞭解應用的質量情況，適配最新的 iOS, Android 官方操作系統，鵝廠的工程師都在使用，快來加入我們吧！
