哪些公司的哪些團隊有嚴格的 code review？

01-06

國內公司,例如百度，阿里，騰訊，小米，360，搜狗，網易有道，新浪微博，豌豆莢等等，外企，例如微軟，IBM，Google， Facebook等等… 在這些公司的技術團隊中，Code Review 具體是如何執行的？你自己切身感受到哪些好處？

微軟前員工。

整體上對於 CR 流程要求還是滿嚴格，commit 之前必須有相關的人做 CR 才能提交（上傳工具就限定了 - 你可以想辦法繞過，但是繞過又出了問題的後果么...）。當然具體效果還要看雙方的自律性。

一進公司的時候國內團隊算是衛星模式，主要開發都在美國。所以 CR 一般要找美國的同事通過郵件來做。各種風格的人都有，有人會很認真寫兩屏的 comment （有人說這個兄弟喜歡錶現，這個也見仁見智）

總之好處是很多的。

1. 當你對系統/語言還不熟悉的時候，找熟悉的人會一下看出一些比較明顯的結構性或者用法的問題。

2. 有的時候自己陷在自己的邏輯裡面，換個人一下就能把問題看出來。

下面的才是重點：

3. 當你有一種「我的代碼要被別人檢查」的感覺的時候，你在準備的時候就會先自己檢查一下，有的地方本來就是因為懶所以沒有重構整理，要 CR 了就不一樣了。

4. 面對面的 CR 經常有很多「這個地方為什麼要這麼做」，當你在解釋的時候實際上是又把思路整理了一下，有的時候問題就是這麼發現的。

--------------------

12.2 補充：

執行層面上，個人認為這個做法的前提是公司以及項目可以承受或者本身適合長周期的開發過程，或者小而精的團隊可以迅速有效的進行 CR。如果人員素質不到位單純複製這個流程可能會有反效果。

根據公司的產品性質可以基本做個判斷。

越是做長期的，企業級的產品的，這方面做的越好，比如Linux和M$系列產品。

越是做短期的，互聯網產品的，這方面做的越差，比如淘寶做各種線上活動等。

執行：同上，各個公司差不多，最好有個舒服的web工具來review，否則彆強推，下面會反感。另外執行起來要有個過程，要經過一定的培訓，要根據自己公司的節奏特點制定要求，可松可緊

體會：

（1）對新人很有用，新人容易犯錯誤和寫出不同命名風格的程序

（2）對質量有一定好處，偶爾（如果寫的人和看的人都認真工作的話）能查出一些bug

（3）要看給你review的人的性格。理想狀況是review關注功能，性能，風格，規範，細節設計，就足夠了。極端情況會碰到一些人以此為政治武器，或者有代碼潔癖或極強的控制欲，那種情況需要儘早當面溝通，無果直接反饋給老闆，不要相互間形成「你給老子找茬，老子也不讓你好過（老子乾脆不好好乾了）」的惡性循環。這是CR比較容易導致的問題。千萬別靠CR的細粒度來樹立自己的威信，只會害人害己。

總結：

有很大的好處，值得貫徹，但是要有有效的對code review的review反饋機制來避免惡性循環（很少發生，但是的確存在）

同事間互相CR代碼可以互相借鑒學習，團隊間配合會更容易，時間長了會有一種認識：代碼是給別人閱讀的不僅僅是解決問題。不會因為你不在了別人無法接手，對於領導來說可以通過這種這種方式了解員工技術特點，評估工作量。

公司內部採用git的工具(gitlab)來進行代碼管理，code review效率很高。