Code Review最佳實踐

Code Review最佳實踐

• 原文連接 : Code Review Best Practices
• 原文做者 : Kevin London
• 譯文出自 : 開發技術前線 www.devtf.cn
• 譯者 : ayyb1988
• 校對者: chaossss
• 狀態 : 完成

在Wiredrive上，咱們作了不少的Code Review。在此以前我歷來沒有作過，這對於我來講是一個全新的體驗，下面來總結一下在Code Review中作的事情以及說說Code Review的最好方式。

簡單的說，Code Review是開發者之間討論修改代碼來解決問題的過程。不少文章談論了Code Review的諸多好處，包括知識共享，代碼的質量，開發者的成長，卻不多討論審查什麼、如何審查。

審查的內容

體系結構和代碼設計

• 單一職責原則：一個類有且只能一個職責。我一般使用這個原則去衡量，若是咱們必須使用「和」來描述一個方法作的事情，這可能在抽象層上出了問題。

• 開閉原則對於面向對象的語言，對象在可擴展方面開放、對在修改方面關閉。若是咱們須要添加另外的內容會怎樣？

• 代碼複用：根據「三振法」,若是代碼被複制一次，雖然不喜歡這種方式，但一般沒什麼問題。但若是再一次被複制，就應該經過提取公共的部分來重構它。

• 換位考慮，若是換位考慮，這行代碼是否有問題？用這種模式是否能夠發現代碼中的問題。

• 用更好的代碼： 若是在一塊混亂的代碼作修改，添加幾行代碼也許更容易，但我建議更進一步，用比原來更好的代碼。

• 潛在的bugs：是否會引發的其餘錯誤？循環是否以咱們指望的方式終止？

• 錯誤處理：錯誤肯定被優雅的修改？會致使其餘錯誤？若是這樣，修改是否有用？

• 效率： 若是代碼中包含算法，這種算法是不是高效？ 例如，在字典中使用迭代，遍歷一個指望的值，這是一種低效的方式。

代碼風格

• 方法名： 在計算機科學中，命名是一個難題。一個函數被命名爲==get_message_queue_name==，但作的倒是徹底不一樣的事情，好比從輸入內容中清除html，那麼這是一個不許確的命名，而且可能會誤導。

• 值名：對於數據結構，==foo== or ==bar== 多是無用的名字。相比==exception==， ==e==一樣是無用的。若是須要(根據語言)儘量詳細，在從新查看代碼時，那些見名知意的命名是更容易理解的。

• 函數長度： 對於一個函數的長度，個人經驗值是小於20行，若是一個函數在50行以上，最好把它分紅更小的函數塊。

• 類的長度：我認爲類的長度應該小於300行，最好在100內。把較長的類分離成獨立的類，這樣更容易理解類的功能。

• 文件的長度： 對於Python，一個文件最多1000行代碼。任何高於此的文件應該把它分離成更小更內聚,看一下是否違背的「單一職責」 原則。

• 文檔：對於複雜的函數來講，參數個數可能較多，在文檔中須要指出每一個參數的用處，除了那些顯而易見的。

• 註釋代碼： 移除任何註釋代碼行。

• 函數參數個數：不要太多， 通常不要超過3個。。
• 可讀性： 代碼是否容易理解？在查看代碼時要不斷的停下來分析它？

測試

• 測試的範圍：我喜歡測試新功能。測試是否全面？是否涵蓋了故障的狀況【好比：網絡，信號等，譯者注】？是否容易使用？是否穩定？全面的測試？性能的快慢？
• 合乎規範的測試：當複查測試時，確保咱們用適當的方式。換句話說，當咱們在一個較低水平測試卻要求獲得指望的結果？Gary Bernhardt建議95％的單元測試，5％的集成測試。特別是在Django項目中，在較高的測試水平上，很容易發現意外bug，建立一個詳細的測試用例，固然認真仔細也是很重要的。

審查代碼

在提交代碼以前，我常常用git添加改變的文件/文件夾,而後經過git diff 來查看作了哪些修改。一般，我會關注以下幾點： 
* 是否有註釋？ 
* 變量名是否見名知意？ 
* …等上面提到的

和著名的橡皮鴨調試法（Rubber Duck Debugging）同樣，每次提交前總體把本身的代碼從新檢查一遍很是有幫助，尤爲是看看有沒有犯低級錯誤。

如何進行Code Review

當Code Review時，會遇到很多問題，我也學會了如何處理，下面是一些方法：

• 提問： 這個函數是如何生效的？若是需求變動，應該作什麼改變？怎麼更容易維護？
• 表揚/獎勵良好的作法：Code Review重要的一點是獎勵開發者的成長和努力。獲得別人的確定是一件很不錯的事情，我儘量多的給人積極的評論。
• 當面討論代替評論。 大部分狀況下小組內的同事是坐在一塊兒的，當面的 code review是很是有效的。
• 說明理由 ：是否還有跟好的方式，證實爲何這樣作是好的。

心態上

• 做爲一個Developer , 不只要Deliver working code, 還要Deliver maintainable code.
• 必要時進行重構，隨着項目的迭代，在計劃新增功能的同時，開發要主動計劃重構的工做項。
• 開放的心態，虛心接受你們的Review Comments。

參考

一些關於clean code的書籍，以下： 
* Clean Code 
* Refactoring 
* All the Small Things by Sandi Metz 
* How to Design a Good API and Why it Matters 
* Discussion on Hacker News

譯者注

一. 參考了 http://jimhuang.cn/?p=59

二. 國內阿里的陳皓寫的關於codereview的文章，也頗有見底，推薦你們看看

1.Code Review中的幾個提示

• 先Review設計實現思路，而後Review設計模式，接着Review成形的骨幹代碼，最後Review完成的代碼，若是程序複雜的話，須要拆成幾個單元或模塊分別Review
• Code Review不要太正式，並且要短
• 學會享受Code Reivew

2.從Code Review 談如何作技術

三. Code Review 工具

Review Board

四.

在Code Review時，要在 意識 方法 心態 習慣 這幾個方面上下功夫，堅持code review，相信咱們會在各方面有很大的提高。