是否要作Code Review？與BAT資深架構師爭論以後的思考

關注個人微信公衆號：小爭哥，獲取更多、更新的技術、非技術分享。
做者：前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的過程當中遇到了哪些問題？