9年間，這個鵝廠團隊是如何讓code review從無到有再到系統化的？

本文最開始是從鵝廠內部的技術論壇的一個問題回答，這裡做一些整理形成一個文章。

記錄下團隊構建以來，9年間code review從無到有到系統化的歷程。

“生產關係與生產力”

回過頭來看，code review也好，各種開發方式也好，很像生產關係（開發方式）與生產力（團隊戰鬥力，文化等）之間的關係，需要匹配，恰當的配合可以互相發展，反之在團隊初期強推“最終版”，恐怕也是不行的。

btw，技術方案的review，結果的定期同步對齊，這些都是價效比超級高，也是一直有的，就不贅述，這裡專門指“code review”的專項；

這裡就記錄下來各個階段各個情況下我們的選擇和結果。


階段1："不review"的開荒時期

在天刀開發的前1,2年，同事們以有經驗的開發者為主，其中大約一半是育碧時期的老同事，還有一些是各個公司裡“次時代”專案的開發者。

這個時期有這麼幾個情況：

• 專案因素：專案在不停的猛烈地趕milestone節點，code review勢必要拖慢節奏
• 技術水平：同事們戰鬥力還都比較好，從結果上看，短時間並沒有看出需要code review的必要
• 團隊文化：團隊文化還都是自由，彼此還有點“抹不開面子”說別人技術哪裡不好，所以review的時候“點到為止”“輕描淡寫“居多
• 認知：code review本身也存在爭議，比如我在13年也寫過這樣的文章：https://blog.csdn.net/toughbro/article/details/12703813
  

所以這裡我們只是在提交milestone的很短的時間裡稍微review下，正常情況下都是不review的。

綜合上面的各項因素，我們可以看出來這一階段的不review，談不上高明，但是有其合理性：

得失

• 確實獲得了速度優勢：這個至關重要，milestone有個閃失，專案前期cancel了就沒的玩了
• 團隊文化和比較強的戰鬥力，都讓code review顯得多餘
• 而且不review，有一些程式碼問題，由於距離上線還早，有充裕的時間來處理，所以不review的代價也沒那麼明顯
  

當然我們對於技術債務還是比較敏感的，是作為專項問題來看，甚至說還有“借貸式開發”的一種操作：

“主動犧牲一些事情來換取速度，詳細記錄下所欠債務和處理方式，拿下階段性的任務，然後接一輪重構和review來把“債務”還清。“

some details:

https://blog.csdn.net/toughbro/article/details/22776277

不過回頭看，這一個階段不review也是比較遺憾，大量的模組遺留實現的不足，尤其是同事們的程式碼能力的建設沒有達到最好，組裡幾個寫程式最強的人，能力與日俱增，但是有些同事則是一直原地踏步。


階段2：上線階段+高速迭代+測試人力不足+版本不出事情==double全量review

實際上我們在《天涯明月刀》《無限法則》上線的時候都經歷過這樣的階段，版本2天一個，但是測試人力又不太夠（恐怕要10x人力才能行），還要保證版本不出事情。

這裡只能靠全量review保證，小組內資深程式一輪review，然後leader再review。

底層級別的review，像我們之前做過一次GC（垃圾回收）的優化，曾經直接把整個game object的底層完完整整過了3遍，review時間與開發的時間相當。

這樣一種方式，確實能夠把事情搞定，且也顛覆了我之前在一些3A專案裡的迭代，測試，安全性的認知。

當然也很傷，對專案組的消耗是非常大的，我個人也常常是review到懷疑人生。。。

更直接的技術文化

這裡的review因為是要強制保證版本質量必須要做的事情，所以直接無視所有阻力落地，review的力度也是很大，一直到程式碼“無懈可擊”為止。

這裡除了程式碼的穩定質量外，一個最大的收穫就是，潛移默化的改變了組內的技術文化，讓直接徹底的技術交流文化能夠沉澱下來，就程式碼進行深入交流，reviewer和被review的人都不會覺得難堪。

進一步這樣的文化和行動，直接產出了更好的“程式碼能力”，有一些同事確實是重演算法輕工程，中間被review的比較厲害，加上確實出現幾次大規模crash，程式碼力上升也是比較快的。


階段3：固化和系統化

到天刀上線穩定運營，《無限法則》也開發進行中，團隊開始有這樣幾個變化：

定位變高了：做出行業一流的東西已經是理所當然的了，寫出不好的程式碼，也沒人能瞪著眼睛說“執行沒問題就行唄”

團隊擴大了幾倍，

–也吸納了很多年輕同事，也包括很多剛畢業的萌新，年輕同事都是擁有100%闖禍率,囧

–單靠leader去hold住團隊完全不現實了，團隊迫切需要更多的高水平的reviewer

可以說對於技術的擴散有了更強的需求和意願，真是恨不得把程式碼力最強的幾個同事直接傳功給專案組。

這裡有幾個要點：

程式碼review讓技術傳承“慣例化”

平時我們也強調技術上的“傳幫帶”很重要，但是實際落地的時候，一方面大家都這麼忙，一方面有時候也礙不開面子，搞不好落一個好為人師，或者對同事不信任等等的感覺。

程式碼review變成制度之後，不做也要做，而且要認真做，老司機面對程式碼能夠放心的講解到深層次的思考，聽者也不會覺得沒面子了。

責任清晰

reviewer要不要對問題負責，這是review中非常重要的一環，沒出事大家都可以開開心心的，但是出了事情，就一定要說清楚。

我們的做法是reviewer對程式碼質量和最終結果要負責的，之前也出現過萌新同學提交出了問題，老司機reviewer也不上心看，結果處理是萌新沒事，老司機受罰：新人出事是難以避免的，整件事情中真正有能力確保事情不出錯的還是老司機reviewer，reviewer這種情況下才是要真正負擔起責任的人。

週會上的典型問題點評

從獨樂樂到眾樂樂，有些典型的程式碼問題，寫的好的地方，週會專門有一個時段用於展示和討論。

經驗上升也就更快了。

code review的消耗問題

這個應該說是最棘手的問題，這裡的核心與根本解決之道還是“以最有效的方式提升團隊程式碼能力”，其餘方法基本都是“掩耳盜鈴”了。

寫程式碼的人，沒有那麼多的毛病，團隊裡技術力強的reviewer也比較多，技術leader也進一步可以解放出來。

sum

是否review以及如何review，在個人看來不是一個“一套真理打天下”的事情，確實是具體問題具體分析，是一個長期建設演化的過程，也是一個逐漸大家理解參透的過程，這樣才能在不斷變化的業務和階段，始終能有最優解。


作者：安柏霖
專欄地址：https://zhuanlan.zhihu.com/p/78728333