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