關(guān)于Code Review的一些心得

　　一、目的是什么

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

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

　　在這種業(yè)務(wù)需求緊張的模式下，F(xiàn)acebook一些開源技術(shù)方案是如何產(chǎn)出的，是非業(yè)務(wù)團(tuán)隊專門做的么？

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

　?。–ode review一直是硅谷一線互聯(lián)網(wǎng)公司的質(zhì)量控制法寶，從Apple到Google，從Facebook到現(xiàn)在的Airbnb和Uber?？杀氖牵瑖鴥?nèi)的人都太聰明，覺得這東西沒用繁瑣，而且減慢開發(fā)速度。有時，我們就是太過聰明。）

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

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

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

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

　　那么我們怎樣來定義這個可讀性強(qiáng)呢？每個人都有自己的標(biāo)準(zhǔn)，怎樣才能在團(tuán)隊里讓大家都認(rèn)可呢？微博的一位工程師在他寫的《關(guān)于爛代碼的那些事》這樣寫到：

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

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

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

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

　　三、那么，該怎樣做呢？

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

　　3.1 SOLID原則

　　這是面向?qū)ο蟮奈鍡l基本原則，我列在下面，在這里就不展開來說了

　　Single responsibility principle

　　Open/closed principle

　　Liskov substitution principle

　　Interface segregation principle

　　Dependency inversion principle

　　3.2 Don’t Repeat Yourself

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

　　3.3 Prefer Composition to Inheritance

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

　　3.4 編碼規(guī)范

　　這個不多說了，可以采用一些行業(yè)里優(yōu)秀的編碼規(guī)范。但是要注意的一點是規(guī)范的作用是保持項目編碼風(fēng)格的統(tǒng)一，不要在規(guī)范上做無意義的爭論。

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

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

　　四、技術(shù)之外的tips

　　在技術(shù)之外還有一些要注意的點，首先最重要的就是要有一個開放的心態(tài)，review的是代碼，而不是具體的人，不要因為對方的review而感覺羞恥，當(dāng)然也不要進(jìn)行人身攻擊。

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

　　第三，code review不應(yīng)該承擔(dān)發(fā)現(xiàn)業(yè)務(wù)邏輯錯誤的責(zé)任，也就是平常我們所說的bug，bug應(yīng)該由單元測試、功能測試、性能測試等方法來保證，不要賦予code review太多的責(zé)任。