Code Review最佳實踐

jopen 9年前發布 | 12K 次閱讀 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的事情,又干邏輯的事情, 這個在低質量的客戶端代碼里很常見。
    </li>
  • 行為是否統一
    • 比如緩存是否統一,錯誤處理是否統一, 錯誤提示是否統一, 彈出框是否統一 等等。
    • 同一邏輯/同一行為 有沒有走同一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>

                      其中有一部分問題,比如一些設計原則, 可預見的效率問題, 開發模式一致性的問題 應該盡早在Design Review階段解決。如果Design階段沒有解決,那至少在Code Review階段也要把它找出來。

                      Style

                      • 可讀性
                        • 衡量可讀性的可以有很好實踐的標準,就是Reviewer能否非常容易的理解這個代碼。 如果不是,那意味著代碼的可讀性要進行改進。
                        </li>
                      • 命名
                        • 命名對可讀性非常重要,我傾向于函數名/方法名長一點都沒關系,必須是能自我闡述的。
                        • 英語用詞盡量準確一點(哪怕有時候需要借助Google Translate,是值得的)
                        • </ul> </li>
                        • 函數長度/類長度
                          • 函數太長的不好閱讀。 類太長了,比如超過了1000行,那你要看一下是否違反的“單一職責” 原則。
                          • </ul> </li>
                          • 注釋
                            • 恰到好處的注釋。 但更多我看到比較差質量的工程的一個特點是缺少注釋。
                            • </ul> </li>
                            • 參數個數
                              • 不要太多, 一般不要超過3個。
                              • </ul> </li> </ul>

                                Review Your Own Code First

                                • 跟著名的橡皮鴨調試法(Rubber Duck Debugging)一樣,每次提交前整體把自己的代碼過一遍非常有幫助,尤其是看看有沒有犯低級錯誤。

                                如何進行Code Review

                                • 多問問題。多問 “這塊兒是怎么工作的?” “如果有XXX case,你這個怎么處理?”
                                • 每次提交的代碼不要太多,最好不要超過1000行,否則review起來效率會非常低。
                                • 當面討論代替Comments。 大部分情況下小組內的同事是坐在一起的,face to face的 code review是非常有效的。
                                • 區分重點,不要舍本逐末。 優先抓住 設計,可讀性,健壯性等重點問題。

                                Code Review的意識

                                • 作為一個Developer , 不僅要Deliver working code, 還要Deliver maintable code.
                                • 必要時進行重構,隨著項目的迭代,在計劃新增功能的同時,開發要主動計劃重構的工作項。
                                • 開放的心態,虛心接受大家的Review Comments。
                                來自:http://jimhuang.cn/?p=59

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!