一、目的是什么

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

　　前幾天看了篇文章，里面有這么一段對(duì)我觸動(dòng)很大：

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

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

　　（Code review一直是硅谷一線(xiàn)互聯(lián)網(wǎng)公司的質(zhì)量控制法寶，從Apple到Google，從Facebook到現(xiàn)在的Airbnb和Uber。可悲的是，國(guó)內(nèi)的人都太聰明，覺(jué)得這東西沒(méi)用繁瑣，而且減慢開(kāi)發(fā)速度。有時(shí)，我們就是太過(guò)聰明。）

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

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

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

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

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

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

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

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

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

　　三、那么，該怎樣做呢？

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

　　3.1 SOLID原則

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

　　Single responsibility principle

　　Open/closed principle

　　Liskov substitution principle

　　Interface segregation principle

　　Dependency inversion principle

　　3.2 Don’t Repeat Yourself

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

　　3.3 Prefer Composition to Inheritance

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

　　3.4 編碼規(guī)范

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

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

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

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

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

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

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