轉(zhuǎn)載自Jim's blog

關(guān)于Code Review的重要性，我相信好的工程師都能認(rèn)識(shí)到。 參考 讓Code Review稱為一種習(xí)慣 和 從Code Review談如何做技術(shù)。

同時(shí)引用一下有人對(duì)Google Code Review的描述：

The biggest thing that makes Google’s code so good is simple: code review. At Google, no code, for any product, for any project, gets checked in until it gets a positive review.

這里主要Summary 一下 如何來(lái)做Code Review. 主要參考 Code Review Best Practices，同時(shí)加上了一些自己的理解。

Code Review 主要Revivew什么

Architecture/Design

單一職責(zé)原則.
這是經(jīng)常被違背的原則。一個(gè)類只能干一個(gè)事情, 一個(gè)方法最好也只干一件事情。 比較常見(jiàn)的違背是一個(gè)類既干UI的事情，又干邏輯的事情, 這個(gè)在低質(zhì)量的客戶端代碼里很常見(jiàn)。
行為是否統(tǒng)一
比如緩存是否統(tǒng)一，錯(cuò)誤處理是否統(tǒng)一， 錯(cuò)誤提示是否統(tǒng)一， 彈出框是否統(tǒng)一 等等。
同一邏輯/同一行為 有沒(méi)有走同一Code Path？低質(zhì)量程序的另一個(gè)特征是，同一行為/同一邏輯，因?yàn)槌霈F(xiàn)在不同的地方或者被不同的方式觸發(fā)，沒(méi)有走同一Code Path 或者各處有一份copy的實(shí)現(xiàn)， 導(dǎo)致非常難以維護(hù)。
代碼污染
代碼有沒(méi)有對(duì)其他模塊強(qiáng)耦合 ？
重復(fù)代碼
主要看有沒(méi)有把公用組件，可復(fù)用的代碼，函數(shù)抽取出來(lái)。
Open/Closed 原則
就是好不好擴(kuò)展。 Open for extension, closed for modification.
面向接口編程 和 不是 面向?qū)崿F(xiàn)編程
主要就是看有沒(méi)有進(jìn)行合適的抽象， 把一些行為抽象為接口。
健壯性
有沒(méi)有考慮線程安全性， 數(shù)據(jù)訪問(wèn)的一致性
對(duì)Corner case有沒(méi)有考慮完整，邏輯是否健壯？有沒(méi)有潛在的bug？
有沒(méi)有內(nèi)存泄漏？有沒(méi)有循環(huán)依賴?（針對(duì)特定語(yǔ)言，比如Objective-C) ？有沒(méi)有野指針？
錯(cuò)誤處理
有沒(méi)有很好的Error Handling？比如網(wǎng)絡(luò)出錯(cuò)，IO出錯(cuò)。
改動(dòng)是不是對(duì)代碼的提升
新的改動(dòng)是打補(bǔ)丁，讓代碼質(zhì)量繼續(xù)惡化，還是對(duì)代碼質(zhì)量做了修復(fù)？
效率/性能
關(guān)鍵算法的時(shí)間復(fù)雜度多少？有沒(méi)有可能有潛在的性能瓶頸。
客戶端程序 對(duì)頻繁消息 和較大數(shù)據(jù)等耗時(shí)操作是否處理得當(dāng)。
其中有一部分問(wèn)題，比如一些設(shè)計(jì)原則， 可預(yù)見(jiàn)的效率問(wèn)題， 開(kāi)發(fā)模式一致性的問(wèn)題 應(yīng)該盡早在Design Review階段解決。如果Design階段沒(méi)有解決，那至少在Code Review階段也要把它找出來(lái)。

Style

可讀性
衡量可讀性的可以有很好實(shí)踐的標(biāo)準(zhǔn)，就是Reviewer能否非常容易的理解這個(gè)代碼。 如果不是，那意味著代碼的可讀性要進(jìn)行改進(jìn)。
命名
命名對(duì)可讀性非常重要，我傾向于函數(shù)名/方法名長(zhǎng)一點(diǎn)都沒(méi)關(guān)系，必須是能自我闡述的。
英語(yǔ)用詞盡量準(zhǔn)確一點(diǎn)（哪怕有時(shí)候需要借助Google Translate，是值得的）
函數(shù)長(zhǎng)度/類長(zhǎng)度
函數(shù)太長(zhǎng)的不好閱讀。 類太長(zhǎng)了，比如超過(guò)了1000行，那你要看一下是否違反的“單一職責(zé)” 原則。
注釋
恰到好處的注釋。 但更多我看到比較差質(zhì)量的工程的一個(gè)特點(diǎn)是缺少注釋。
參數(shù)個(gè)數(shù)
不要太多， 一般不要超過(guò)3個(gè)。
Review Your Own Code First
跟著名的橡皮鴨調(diào)試法（Rubber Duck Debugging）一樣，每次提交前整體把自己的代碼過(guò)一遍非常有幫助，尤其是看看有沒(méi)有犯低級(jí)錯(cuò)誤。
如何進(jìn)行Code Review

多問(wèn)問(wèn)題。多問(wèn) “這塊兒是怎么工作的？” “如果有XXX case，你這個(gè)怎么處理？”
當(dāng)面討論代替Comments。 大部分情況下小組內(nèi)的同事是坐在一起的，face to face的 code review是非常有效的。
區(qū)分重點(diǎn)，不要舍本逐末。 優(yōu)先抓住 設(shè)計(jì)，可讀性，健壯性等重點(diǎn)問(wèn)題。
Code Review的意識(shí)

作為一個(gè)Developer , 不僅要Deliver working code, 還要Deliver maintable code.
必要時(shí)進(jìn)行重構(gòu)，隨著項(xiàng)目的迭代，在計(jì)劃新增功能的同時(shí)，開(kāi)發(fā)要主動(dòng)計(jì)劃重構(gòu)的工作項(xiàng)。
開(kāi)放的心態(tài)，虛心接受大家的Review Comments。