Code Review最佳實踐
關于Code Review的重要性,我相信好的工程師都能認識到。 參考 讓Code Review稱為一種習慣 和 從Code Review談如何做技術。
同時引用一下有人對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
-
單一職責原則.
- 這是經常被違背的原則。一個類只能干一個事情, 一個方法最好也只干一件事情。 比較常見的違背是一個類既干UI的事情,又干邏輯的事情, 這個在低質量的客戶端代碼里很常見。
-
行為是否統一
- 比如緩存是否統一,錯誤處理是否統一, 錯誤提示是否統一, 彈出框是否統一 等等。
- 同一邏輯/同一行為 有沒有走同一Code Path?低質量程序的另一個特征是,同一行為/同一邏輯,因為出現在不同的地方或者被不同的方式觸發,沒有走同一Code Path 或者各處有一份copy的實現, 導致非常難以維護。 </ul> </li>
-
代碼污染
- 代碼有沒有對其他模塊強耦合 ? </ul> </li>
-
重復代碼
- 主要看有沒有把公用組件,可復用的代碼,函數抽取出來。 </ul> </li>
-
Open/Closed 原則
- 就是好不好擴展。 Open for extension, closed for modification. </ul> </li>
-
面向接口編程 和 不是 面向實現編程
- 主要就是看有沒有進行合適的抽象, 把一些行為抽象為接口。 </ul> </li>
-
健壯性
- 有沒有考慮線程安全性, 數據訪問的一致性
- 對Corner case有沒有考慮完整,邏輯是否健壯?有沒有潛在的bug?
- 有沒有內存泄漏?有沒有循環依賴?(針對特定語言,比如Objective-C) ?有沒有野指針? </ul> </li>
-
錯誤處理
- 有沒有很好的Error Handling?比如網絡出錯,IO出錯。 </ul> </li>
-
改動是不是對代碼的提升
- 新的改動是打補丁,讓代碼質量繼續惡化,還是對代碼質量做了修復? </ul> </li>
-
效率/性能
- 關鍵算法的時間復雜度多少?有沒有可能有潛在的性能瓶頸。
- 客戶端程序 對頻繁消息 和較大數據等耗時操作是否處理得當。 </ul> </li> </ul>
-
可讀性
- 衡量可讀性的可以有很好實踐的標準,就是Reviewer能否非常容易的理解這個代碼。 如果不是,那意味著代碼的可讀性要進行改進。
-
命名
- 命名對可讀性非常重要,我傾向于函數名/方法名長一點都沒關系,必須是能自我闡述的。
- 英語用詞盡量準確一點(哪怕有時候需要借助Google Translate,是值得的) </ul> </li>
-
函數長度/類長度
- 函數太長的不好閱讀。 類太長了,比如超過了1000行,那你要看一下是否違反的“單一職責” 原則。 </ul> </li>
-
注釋
- 恰到好處的注釋。 但更多我看到比較差質量的工程的一個特點是缺少注釋。 </ul> </li>
-
參數個數
- 不要太多, 一般不要超過3個。 </ul> </li> </ul>
- 跟著名的橡皮鴨調試法(Rubber Duck Debugging)一樣,每次提交前整體把自己的代碼過一遍非常有幫助,尤其是看看有沒有犯低級錯誤。
- 多問問題。多問 “這塊兒是怎么工作的?” “如果有XXX case,你這個怎么處理?”
- 每次提交的代碼不要太多,最好不要超過1000行,否則review起來效率會非常低。
- 當面討論代替Comments。 大部分情況下小組內的同事是坐在一起的,face to face的 code review是非常有效的。
- 區分重點,不要舍本逐末。 優先抓住 設計,可讀性,健壯性等重點問題。
- 作為一個Developer , 不僅要Deliver working code, 還要Deliver maintable code.
- 必要時進行重構,隨著項目的迭代,在計劃新增功能的同時,開發要主動計劃重構的工作項。
- 開放的心態,虛心接受大家的Review Comments。
Review Your Own Code First
如何進行Code Review
Code Review的意識
其中有一部分問題,比如一些設計原則, 可預見的效率問題, 開發模式一致性的問題 應該盡早在Design Review階段解決。如果Design階段沒有解決,那至少在Code Review階段也要把它找出來。
Style
本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!