漫談Code Review的錯誤實踐

從剛開始工作時到現在，已經寫了7年的代碼，大部分代碼都被人review過，自己也review了很多人的代碼。在上一家公司的時候，我負責的一輪面試是專門進行Code Review的練習和經驗談。

通過在工作/面試中做Code Review的過程，有一些自己任務錯誤的實踐分享出來，也歡迎大家來一起讨論。

什麼時候都一定要做Code Review

Code Review是否一定有必要呢？我的答案是不一定。

我覺的需要分時間，分項目。

在公司創業之始，1，2兩個人吭哧吭哧的把整個産品從0到1的搭建出來，Code Review既沒有條件（沒有别人可以review），也沒有必要，将産品實作，讓項目活下來才是最重要的。

線上上出了Bug，分分鐘損失成百上千的時候，顯然以救急為主，等Code Review黃花菜都涼了。當然這裡分情況，如果是非常顯而易見的bug，比如你非常确定是一個條件寫反了，那麼不用廢話趕緊上。如果這個修改不那麼輕巧，那麼多一雙眼睛看一遍往往會大大降低再次引入bug的幾率。

Code Review主要是用來讓别人檢查Bug的

将Code Review視為别人替自己檢查Bug的手段，可能代表了相當一部分程式員的想法。

在Code Review中查錯确實是一個重要的目的，但并不應該成為唯一的目的。

除了檢查Bug，Code Review還是：

1. 維持代碼品質、統一代碼風格的手段。每個人的技術能力，背景各不相同，放任自由的發揮可以寫出很多品質不同，風格迥異的代碼。通過Code Review，可以迫使大家将代碼品質維持在大家都可以接受的程度，并且是的項目的代碼風格盡量統一。
2. 一個互相學習的過程。 對于初學者，我們可以指出其代碼中的風格、設計等方面的不足，可以直接“教育”别人該怎麼寫代碼。反過來，在Review别人的代碼時，我們也可以學習作者是怎麼寫代碼的，如何調用的API，用到了哪些設計模式。不僅新手可以向老鳥學習，老鳥們也有很多機會向新手們學習。我就是通過Review畢業的同僚的代碼學些的Java的JOOQ架構。
3. 一個了解同僚工作内容的機會。程式員平時可能會比較關注在自己的開發任務上，而自己的同僚正在做什麼，怎麼做，這些資訊通過Code Review可以最直覺的了解。比如你的同僚可能需要和你改同一個檔案，這樣你可以知道他改的思路，可以避免在代碼合并之前産生沖突。

初級工程師的代碼需要檢查Bug，進階工程師的代碼不需要檢查Bug

很多時候，對于初級工程師的代碼，大家都會很踴躍的去review，并且會有以找到代碼中的Bug而顯示自己的“資深”的榮耀。但是對于進階工程師寫的代碼，要麼人家根本不給你建Code Review，要麼即使把你加到Code Review裡，也礙于自己的地位不敢去提意見。或者大家都對進階工程師給予了充分的信任，對于他們建立的Code Review請求都不怎麼仔細看，直接LGTM（Looks Good To Me）。

然而這是不對的， 初級工程師寫小bug，進階工程師寫要命的bug。

初級工程師做的任務也比較初級，而進階工程師做的任務也會比較重要。如果你去關注一下公司的重大生産環境事故，事故的引起者是進階工程師的可能性遠遠大于初級工程師。這和“出車禍的都是老司機”，“淹死的都是會遊泳的”的道理一樣，“進階”工程師由于專注于高屋建瓴的設計，反而有可能忽視了代碼中的細節。同時“進階”工程師對于自身的技術信心較足，往往會忽視一些基本的自我測試等環節。

是以不論初級，進階工程師寫的代碼，Code Review都是必要的，隻是側重點可能會不同。在檢查Bug這件事上，我們在戰略上相信同僚，戰術上要懷疑同僚。

Code Review提的問題越多越好

我在工作中遇到過一些這樣的“Code Review噴子”，同僚送出了一段100行不到的代碼，被洋洋灑灑的提了十幾二十處問題。同僚對在有些問題上回複了一下自己的意見，雙方就一些蘿蔔白菜的問題蓋了十幾層高樓。結果兩三天過去了，論戰還在進行。

我曾經在被這樣“猛烈”的Code Review轟炸中，為了讓所有的Reviewer都高興，前後更改數十次，每次修改都有不同的同僚提出各種各樣的意見。并且最後關頭為了一個設計上的分歧，将代碼進行了大的重構，最終終于被接受（Accept）。然而代碼合并之後卻出現了低級的Bug，回頭查了一下，正是最後一次的大重構引入了這個bug。為什麼會出現這樣的結果呢？一個Code Review進行的時間越長，Author的耐心越來越差，Reviewer也越來越隻關注他們“希望”你做出的改變，反而屬于撿了芝麻丢了西瓜。

如果一個Code Review中的送出太多，對于review過程是不利的。每個Reviewer的記憶是有限的， 可能隻能記得第一二次代碼的修改。如果一次Code Review中出現多個送出，審閱最新的送出則會喪失之前的上下文，則會出現我上面遇到的問題。