一、目的是什么

　　做任何事情都要有一個目的，那么我們做code review的目的是什么呢？本來開發工期就非常緊了，特別是身處中國這個大環境下的互聯網公司，老板恨不得要你二十四小時連軸轉，為什么還要花那么多時間去做code review呢？我認為code review的目的在于提升代碼質量。

　　前幾天看了篇文章，里面有這么一段對我觸動很大：

　　在這種業務需求緊張的模式下，Facebook一些開源技術方案是如何產出的，是非業務團隊專門做的么？

　　我想說的是即使業務需求緊張，也一樣把代碼好好寫好，另外有牛逼的tech lead和嚴格的code review，總的質量也不是很差。國內有一點很不好：經常沒有code review；而且技術人員觀念不好，把要寫的代碼當差事，只要能完成能用就好。所以就越來越操。

　　（Code review一直是硅谷一線互聯網公司的質量控制法寶，從Apple到Google，從Facebook到現在的Airbnb和Uber。可悲的是，國內的人都太聰明，覺得這東西沒用繁瑣，而且減慢開發速度。有時，我們就是太過聰明。）

　　所以我們不要總是拿沒時間來當做借口，如果對代碼質量沒有一定的追求，給再多時間也是沒用的。業務需求緊張需要通過提高工作效率來解決，而不是不花精力提高代碼質量。另外，站在一個項目的生命周期來看，寫爛代碼真的會比寫好代碼花的時間更少么？

　　二、好代碼最重要的特征是什么？

　　既然做code review的目的是提高代碼質量了，那么什么樣的代碼才能算是好的代碼呢？最開始這個標題我寫的是「什么樣的代碼才是好代碼？」，后來我想了下這個問題太大，我無法對「好代碼」簡單的下一個定義，真正討論起來估計得單獨寫一篇文章了，所以先按住這個話題，換成簡單的「好代碼的最重要的特征是什么？」。

　　我覺著好代碼最重要的特征是可讀性強，這樣才能讓和你協作的同學以及未來的你自己能夠不用想太多就能看得懂，畢竟花在維護代碼上的時間要遠遠超過寫這段代碼花的時間。每新增一行代碼就會多增加一份維護成本，而可讀性強的代碼可以把維護成本降到最低。

　　那么我們怎樣來定義這個可讀性強呢？每個人都有自己的標準，怎樣才能在團隊里讓大家都認可呢？微博的一位工程師在他寫的《關于爛代碼的那些事》這樣寫到：

　　在很多跟代碼質量有關的書里都強調了一個觀點：程序首先是給人看的，其次才是能被機器執行，我也比較認同這個觀點。在評價一段代碼能不能讓人看懂的時候，我習慣讓作者把這段代碼逐字翻譯成中文，試著組成句子，之后把中文句子讀給另一個人沒有看過這段代碼的人聽，如果另一個人能聽懂，那么這段代碼的可讀性基本就合格了。

　　用這種判斷方式的原因很簡單：其他人在理解一段代碼的時候就是這么做的。閱讀代碼的人會一個詞一個詞的閱讀，推斷這句話的意思，如果僅靠句子無法理解，那么就需要聯系上下文理解這句代碼，如果簡單的聯系上下文也理解不了，可能還要掌握更多其它部分的細節來幫助推斷。大部分情況下，理解一句代碼在做什么需要聯系的上下文越多，意味著代碼的質量越差。

　　逐字翻譯的好處是能讓作者能輕易的發現那些只有自己知道的、沒有體現在代碼里的假設和可讀性陷阱。無法從字面意義上翻譯出原本意思的代碼大多都是爛代碼，比如“ms代表messageService“，或者“ms.proc（）是發消息“，或者“tmp代表當前的文件”。

　　我很認可這個說法，在這個基礎上，我一直堅持認為雖然一個能把一件事情描述清楚的人寫的代碼不一定可讀性強，但是一個無法將一件事情描述清楚的人寫出來的代碼可讀性肯定很差。

　　三、那么，該怎樣做呢？

　　說了那么多了，具體怎樣落地到現實工作中呢？即使按照前文所說的把代碼逐字翻譯成中文講給其他同學聽，也一樣可能由于認知問題導致對方聽不懂，比如你認為很基礎的概念可能別人并不了解。所以我認為大家要遵循一些基本原則，這樣才能有效的溝通。

　　3.1 SOLID原則

　　這是面向對象的五條基本原則，我列在下面，在這里就不展開來說了

　　Single responsibility principle

　　Open/closed principle

　　Liskov substitution principle

　　Interface segregation principle

　　Dependency inversion principle

　　3.2 Don’t Repeat Yourself

　　一般對這條原則的理解是對于同樣的功能不要直接copy原來的代碼，而是要抽象出一個公用的方法。但是實際上對同樣的功能用不同的思路或者代碼去實現也是一種浪費。比如常見的日志處理、異常處理邏輯。

　　3.3 Prefer Composition to Inheritance

　　這條原則跟前面提到的OOP的SOLID原則里面的Interface segregation principle有點重合之處。隨著業務需求的不斷迭代，小的組件逐漸會演變成大的組件，在這個過程中駕馭的難度會逐步提升，而如果在不斷迭代的過程中不斷抽象出小的組件，則可以在業務功能復雜的同時保持代碼的簡潔。比如不管是飛機還是汽車火車都是會移動的，而我在使用時只需知道這個對象是可移動的即可，至于這個對象是飛機還是汽車我并不關心。

　　3.4 編碼規范

　　這個不多說了，可以采用一些行業里優秀的編碼規范。但是要注意的一點是規范的作用是保持項目編碼風格的統一，不要在規范上做無意義的爭論。

　　3.5 如果不具備抽象的能力，那就重復吧

　　這是一個比較殘酷的也比較常見的現實，看了一大摞的書廢了老大的勁終于抽象出了一個組件，但是最后的結果卻是加大了維護成本。所以如果你覺著無法很好的去抽象，就直接用最粗魯的重復代碼吧，畢竟這樣別人還能看得懂，比抽象出來后還要再寫一大堆的if else好多了。

　　四、技術之外的tips

　　在技術之外還有一些要注意的點，首先最重要的就是要有一個開放的心態，review的是代碼，而不是具體的人，不要因為對方的review而感覺羞恥，當然也不要進行人身攻擊。

　　其次，要把握review的粒度，不要一下發起一個非常大的PR，這樣會給review的同學特別大的壓力。比如一個PR里最好不要同時既有重構又有新特性的開發，或者憋到最后這個版本都要開發完了才一起提交一個PR。review應該是在平時的工作中持續進行的，而不是類似里程碑的總結之類的東西。

　　第三，code review不應該承擔發現業務邏輯錯誤的責任，也就是平常我們所說的bug，bug應該由單元測試、功能測試、性能測試等方法來保證，不要賦予code review太多的責任。