轉(zhuǎn)載自Jim's blog
關(guān)于Code Review的重要性，我相信好的工程師都能認識到。 參考 讓Code Review稱為一種習(xí)慣 和 從Code Review談如何做技術(shù)。
同時引用一下有人對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 一下 如何來做Code Review. 主要參考 Code Review Best Practices，同時加上了一些自己的理解。
Code Review 主要Revivew什么
Architecture/Design
單一職責(zé)原則.
這是經(jīng)常被違背的原則。一個類只能干一個事情, 一個方法最好也只干一件事情。 比較常見的違背是一個類既干UI的事情，又干邏輯的事情, 這個在低質(zhì)量的客戶端代碼里很常見。
行為是否統(tǒng)一
比如緩存是否統(tǒng)一，錯誤處理是否統(tǒng)一， 錯誤提示是否統(tǒng)一， 彈出框是否統(tǒng)一 等等。
同一邏輯/同一行為 有沒有走同一Code Path？低質(zhì)量程序的另一個特征是，同一行為/同一邏輯，因為出現(xiàn)在不同的地方或者被不同的方式觸發(fā)，沒有走同一Code Path 或者各處有一份copy的實現(xiàn)， 導(dǎo)致非常難以維護。
代碼污染
代碼有沒有對其他模塊強耦合 ？
重復(fù)代碼
主要看有沒有把公用組件，可復(fù)用的代碼，函數(shù)抽取出來。
Open/Closed 原則
就是好不好擴展。 Open for extension, closed for modification.
面向接口編程 和 不是 面向?qū)崿F(xiàn)編程
主要就是看有沒有進行合適的抽象， 把一些行為抽象為接口。
健壯性
有沒有考慮線程安全性， 數(shù)據(jù)訪問的一致性
對Corner case有沒有考慮完整，邏輯是否健壯？有沒有潛在的bug？
有沒有內(nèi)存泄漏？有沒有循環(huán)依賴?（針對特定語言，比如Objective-C) ？有沒有野指針？
錯誤處理
有沒有很好的Error Handling？比如網(wǎng)絡(luò)出錯，IO出錯。
改動是不是對代碼的提升
新的改動是打補丁，讓代碼質(zhì)量繼續(xù)惡化，還是對代碼質(zhì)量做了修復(fù)？
效率/性能
關(guān)鍵算法的時間復(fù)雜度多少？有沒有可能有潛在的性能瓶頸。
客戶端程序 對頻繁消息 和較大數(shù)據(jù)等耗時操作是否處理得當(dāng)。
其中有一部分問題，比如一些設(shè)計原則， 可預(yù)見的效率問題， 開發(fā)模式一致性的問題 應(yīng)該盡早在Design Review階段解決。如果Design階段沒有解決，那至少在Code Review階段也要把它找出來。Style
可讀性
衡量可讀性的可以有很好實踐的標(biāo)準(zhǔn)，就是Reviewer能否非常容易的理解這個代碼。 如果不是，那意味著代碼的可讀性要進行改進。
命名
命名對可讀性非常重要，我傾向于函數(shù)名/方法名長一點都沒關(guān)系，必須是能自我闡述的。
英語用詞盡量準(zhǔn)確一點（哪怕有時候需要借助Google Translate，是值得的）
函數(shù)長度/類長度
函數(shù)太長的不好閱讀。 類太長了，比如超過了1000行，那你要看一下是否違反的“單一職責(zé)” 原則。
注釋
恰到好處的注釋。 但更多我看到比較差質(zhì)量的工程的一個特點是缺少注釋。
參數(shù)個數(shù)
不要太多， 一般不要超過3個。
Review Your Own Code First
跟著名的橡皮鴨調(diào)試法（Rubber Duck Debugging）一樣，每次提交前整體把自己的代碼過一遍非常有幫助，尤其是看看有沒有犯低級錯誤。
如何進行Code Review多問問題。多問 “這塊兒是怎么工作的？” “如果有XXX case，你這個怎么處理？”
當(dāng)面討論代替Comments。 大部分情況下小組內(nèi)的同事是坐在一起的，face to face的 code review是非常有效的。
區(qū)分重點，不要舍本逐末。 優(yōu)先抓住 設(shè)計，可讀性，健壯性等重點問題。
Code Review的意識作為一個Developer , 不僅要Deliver working code, 還要Deliver maintable code.
必要時進行重構(gòu)，隨著項目的迭代，在計劃新增功能的同時，開發(fā)要主動計劃重構(gòu)的工作項。
開放的心態(tài)，虛心接受大家的Review Comments。
