【轉載】 漫談Code Review的錯誤實踐

原文地址：

https://www.cnblogs.com/chaosyang/p/code-review-wrong-practices.html

 

 

 

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

 

 

 

 

從剛開始工做時到如今，已經寫了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中出現多個提交，審閱最新的提交則會喪失以前的上下文，則會出現我上面遇到的問題。

咱們作Code Review的目的並非追求完美的Code，世界上沒有完美的Code，任何代碼片斷，只要足夠長，均可以有可改進的地方。每一個人心中的完美代碼各不相同，有的人喜歡這樣寫，有的人喜歡那樣寫。在不違反前面說的代碼質量、統一風格的基礎上，應該遵照「誰寫代碼誰作主」的原則。

 

 

 

 

 

 

 

 

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