關注我的微信公眾號：小爭哥，獲取更多、更新的技術、非技術分享。
作者：前Google工程師，5萬人訂閱《資料結構和演算法之美》專欄作者。
希望通過我加速你的技術、職場進步。
Code Review中文叫程式碼審查，據我所知在很多網際網路企業裡面幾乎沒有很好的實踐，包括很多像BAT一樣的大廠，特別是一些業務開發部門，都沒有Code Review流程，程式碼寫完之後隨手提交，然後丟給測試狠命測．
之前跟一個有十幾年開發經驗的現BAT某家的資深員工提起Code Review時，其很篤定的講不可能很好的執行，比較浪費時間，虎頭蛇尾等等，一頓否定，又當我提起在Google內部開發中Code Review是一個執行的很好且已經習以為常的開發流程時，他竟然倚老賣老的說絕對不相信．
一個技術不錯，號稱架構師，玩轉各種框架，中介軟體的資深IT從業者，居然對Code Review有如此的偏見，是哪裡出了問題，這也是我寫這篇文章的原因。本文不是一篇講如何做Code Review的方法論，儘管有所涉及，但更多的是對Code Review執行過程中很多團隊會遇到的一些問題的思考。
1. Code Review的意義有多大？
首先來說下Code Review的意義，當開發團隊對Code Review認可了，意識到它的必要和好處了，我想，弄清楚如何快速有效的Code Review，對充滿高智商、高學習能力的IT界工程師來講，也就不是什麼難事了。
1）三人行必有我師
永遠不要覺得自己很牛逼，或者程式碼很牛逼，不需要別人Review；也永遠不要覺得自己水平一般，沒有資格給別人Review；更不要覺得大牛讓你Review程式碼就只是缺少你的一個approve，可以隨便掃一眼就LGTM（looks good to me）了。
谷歌在Code Review方面執行的很好，儘管谷歌的工程師的平均研發水平都很高，但你會發現，只要是提交Review的程式碼，照樣會有很多comment（修改意見）。即便自己覺得足夠牛逼的程式碼，只要經過不停的推敲，都是有持續改進的空間的。
2）高手之間的過招在細節
只要對技術有追求的團隊，就不能把開發當成外包：只要程式碼可以執行就提交，黑盒狠命測一把，驗出bug再修復。高手之間過招看的是細節。不同水平的團隊，開發相同的業務或者框架，開發出來的東西雖然都能跑，但在可讀性，擴充套件性，效能，可靠性等各種非功能性方面都可能差別很多。
3）Code Review是摒棄個人英雄主義的作坊式開發模式的有效手段
在一個成熟的公司裡，所有的架構設計、實現，都應該是一個團隊的產出。儘管這個過程可能會有某個人來主導，但應該是經過整個團隊共同智慧的結晶。
如果一個人默默的寫程式碼提交，不經過團隊的Review，這樣的程式碼蘊含的是一個人的智慧。程式碼的質量完全依賴於這個人的技術水平。這就會導致程式碼質量層次不齊。如果經過團隊多人Review，打磨，則程式碼蘊含的是整個團隊的智慧，可以保證程式碼按照團隊中的最高水準輸出。
4）Code Review過程是對程式碼可讀性的考察
我覺得，程式碼的可讀性可能比任何方面（擴充套件性等）都重要。可讀性好，代表了後期維護成本低，線上bug容易排查，新人容易熟悉程式碼，老人離職時程式碼容易接手，而且可讀性好，也說明程式碼足夠簡單，出錯可能性小，程式碼的組織架構合理。
而Code Review是考察程式碼的可讀性的一種很好的手段。如果程式碼審查者（Reviewer）很費勁才能看懂你的程式碼，說明這段程式碼的可讀性就有待提高了。
5）Code Review可以提高程式碼質量
這個很多人都認可，前面也講到了。不過我補充一點我的體會：有句名言：旁觀者清，當局者迷。自己寫程式碼的時候，寫的暈乎乎的，有時候將程式碼提交review board（code review的工具介面）之後，自己的改動都放到一塊，清晰可見，一目瞭然，有時候還沒有等其他同事review，自己就先發現了很多問題。
6）Code Review過程是一種mentor（傳幫帶）的有效途徑
團隊講求傳幫帶，如何來做呢？當然，業務上面，我們可能通過文件，口口相傳，那技術呢？如何培養初級工程師的技術能力呢？Code Review就是一種很好的途徑，每次Code Review的過程都是一次真實的案例講解，是從大牛身上學習技術的很好途徑。
7）Code Review保證不止一人對程式碼熟悉
如果一段程式碼只有一個人熟悉，如果這個同事休假了離職了，交接起來就比較費勁，有時候單純看程式碼還看不大懂，又要跟PM、業務團隊、或者其他技術團隊，再重複來一輪溝通，搞的其他團隊的人都很煩你。而Code Review保證任何程式碼都至少同時有兩個同事熟悉，除非兩個同事同時離職:（
8）Code Review可以打造良好的技術氛圍
提交程式碼Review的人，希望自己寫的程式碼足夠牛逼，畢竟被同事Review出很多爛程式碼，是件很丟人的事情。而做Code review的人，也希望自己儘可能的提出有建設性第一件，展示自己的能力。這本身就能增進技術交流，活躍技術氛圍，培養大家的Geek精神，對程式碼優美的追求。
9）Code Review是一種溝通方式
Talk is cheap，show me the code。怎麼"show"，通過Code Review工具來"show"，這樣也方便別人反饋意見。特別是跨不同辦公室、跨時區的溝通，Code Review是一種很好的溝通方式。我今天白天寫的程式碼，明天來上班的時候，跨時區的同事已經幫我Review好了，豈不是感覺很好。
10）Review提高大家自律性
開發過程難免有人不自律，或者偶爾有僥倖心理，反正也沒人看，隨便寫寫就提交了。Code Review過程相當於一次程式碼直播，曝光dirty Code，有一定的威懾力，大家就不敢隨便應付一下就提交程式碼了。
2. Code Review反對聲音有哪些？
上面講了這麼多Code Review的意義，雖然大部分人都認可，但還是有很多反對的聲音，我們來看看都有哪些反對的聲音？
1）有人認為Code Review流程太長，太浪費時間，特別是業務逼，工期緊的時候，今天改的程式碼，明天就要上，如果等同事Review，同事還有可能沒時間。
我所經歷的專案，還沒有一個因為工期緊導致沒有時間Code Review的。而且Code Review熟練之後，並不需要花費太長的時間。儘管開始做Code Review的時候，你可能因為不熟練，需要有一個check list對照著來Review，比較耗時，但當你熟練之後，Code Review就像鍵盤盲打一樣，你已經忘記了哪個手指按的是哪個鍵了，掃一遍程式碼就能揪出絕大部分問題。
2）有人認為有了黑盒測試，寫的程式碼給測試團隊測試就ok了，Code Review沒有必要，ROI（投入產出比）不高。
黑盒測試只能測試程式碼的正確性，對於很多非功能性的，比如程式碼的可讀性，擴充套件性，組織結構是否合理，效能問題等都是無法考察的。
3）有人認為業務一直在變，今天寫的明天可能就改，程式碼有可能不會維護很久，程式碼寫得太好也沒用。
這種現象在遊戲開發、一些早期的創業公司、或者專案驗證階段比較常見，講求短平快，先驗證產品，再優化技術，如果確實面對的還只是生存問題，程式碼質量確實不是首要的，特殊情況下，不做Code Review是支援的！
3. Code Review如何落地執行？
知易行難，有些leader已經認識到Code Review的必要性，但執行起來又困難重重，下面羅列了我所經歷的一些困難，以及相應的應對策略。
1）團隊成員水平比較低，不知道Review什麼，也Review不出什麼。自己程式碼都沒寫明白，不知道什麼是好的程式碼，什麼是差的，更不要說告訴別人了，大眼瞪小眼，只能Review點語法的了。
這種情況也挺常見，不過沒關係，團隊的技術水平都是可以培養的。我們可以先讓資深同事。技術好的同事、或者leader，來review其他所有的人的程式碼。Review的過程也是一種mentor的過程，慢慢的大家都知道哪樣的程式碼有問題，應該從哪些方面Review。雖然這可能會有一個相當長的過程，但如果真想在團隊中實行Code Review，這不失是一種曲線救國的方法。
2）還有一種情況是，開始的時候大家Code Review都還挺認真，但是時間長了，大家覺得這事跟KPI無關，而且我還要看別人的程式碼，理解業務，多浪費我時間啊。慢慢地就會發生這樣的情況：有人提交了程式碼，隨便抓個人Review，Review的人也不認真，隨便掃一眼就點approve了。一旦發生破窗效應，Code Review也就會變成流於形式了。
我的對策是：一方面，要明確的告訴Code Review的重要性，要嚴格執行，讓大家不要懈怠；另一方面，是否可以間接的跟KPI，升職等聯絡在一塊，senior的工程師有義務做Code Review，就像技術面試一樣。再次，想辦法活躍團隊的技術氛圍，把Code Review作為一種展示自己技術的機會，帶動起大家Code Review的積極性，提高大家都Code Review的認同感（也算是洗腦吧）。
多說幾句：Google的Code Review是做的很好的，可以說是谷歌保持程式碼高質量最有效的手段之一。Google的Code Review非常嚴格，多一個空行，多一個空格，註釋有拼錯的單詞，變數命名的不夠好，都被指出來要求修改。而且，所有的專案都要求Code Review。
歡迎留言區說說你對Code review的看法，你們公司是否有Code Review，在Code Review的過程中遇到了哪些問題？