Android開發規範：CodeReview規範

我的新書《Android App開發入門與實戰》已于2020年8月由人民郵電出版社出版，歡迎購買。點選進入詳情

目錄

CodeReview目的

CodeReview清單 VS Bad Smell

CodeReview方式

CodeReview輸出

CodeReview目的

老生常談==>>>

代碼有這幾種級别：1，可編譯；2，可運作；3，可測試；4，可讀；5，可維護；6，可重用。

通過自動化測試的代碼隻能達到第3層次，而通過code Review的代碼可以上升到更高的層次。

1、提升開發人員代碼編寫品質

2、現有版本的優化

3、開發人員間代碼和業務互相熟悉

CodeReview清單 VS Bad Smell

以下摘抄自網絡：

正常項

• 代碼能夠工作麼？它有沒有實作預期的功能，邏輯是否正确等。
• 所有的代碼是否簡單易懂？
• 代碼符合你所遵循的程式設計規範麼？這通常包括大括号的位置，變量名和函數名，行的長度，縮進，格式和注釋。
• 是否存在多餘的或是重複的代碼？
• 代碼是否盡可能的子產品化了？
• 是否有可以被替換的全局變量？
• 是否有被注釋掉的代碼？
• 循環是否設定了長度和正确的終止條件？
• 是否有可以被庫函數替代的代碼？
• 是否有可以删除的日志或調試代碼？

安全

• 所有的資料輸入是否都進行了檢查（檢測正确的類型，長度，格式和範圍）并且進行了編碼？
• 在哪裡使用了第三方工具，傳回的錯誤是否被捕獲？
• 輸出的值是否進行了檢查并且編碼？
• 無效的參數值是否能夠處理？

文檔

• 是否有注釋，并且描述了代碼的意圖？
• 所有的函數都有注釋嗎？
• 對非正常行為和邊界情況處理是否有描述？
• 第三方庫的使用和函數是否有文檔？
• 資料結構和計量機關是否進行了解釋？
• 是否有未完成的代碼？如果是的話，是不是應該移除，或者用合适的标記進行标記比如‘TODO’？

測試

• 代碼是否可以測試？比如，不要添加太多的或是隐藏的依賴關系，不能夠初始化對象，測試架構可以使用方法等。
• 是否存在測試，它們是否可以被了解？比如，至少達到你滿意的代碼覆寫(code coverage)。
• 單元測試是否真正的測試了代碼是否可以完成預期的功能？
• 是否檢查了數組的“越界“錯誤？
• 是否有可以被已經存在的API所替代的測試代碼？

代碼審查單還可以利用現有的代碼檢測工具來實作，比如findbugs等等。

同樣，代碼審查清單也需要不斷疊代更新優化，每個團隊得有一個CodeReview代碼審查清單(CodeReview-checklist)。  

補充

關于CodeReview清單，另外補充一點：

每個團隊都需要有自己的技術選型規範，比如網絡請求用什麼架構，圖檔加載用什麼架構，Adapter用什麼方案等等。

因為每一個功能可能有多種實作方式，為了不在一個項目裡面對同一種功能采用多種實作方式（比如使用Glide，又引入了Picasso），保證統一性，是以我們在CodeReview的時候也需要對這一塊進行檢查。

CodeReview方式

1、face 2 face

2、抓重點，比如設計、架構、可讀、健壯

3、所有人參與codereview

4、

簡單點：技術經理可以從這周送出的代碼中找出典型的代碼片段，拿出來進行講解和讨論；

完善點：每個開發者互相codereview，找出有問題的代碼片段，拿來給大家進行讨論。

靈活點：遇到問題就可以跟開發人員面對面或者IM溝通。

CodeReview輸出

每個項目團隊每周CodeReview後需要在文檔管理系統上總結CodeReview的内容，按照CodeReview-checklist彙報。