code review筆記
最終目標: 讓code base越來越好
- 符合各檢查項目，且能改善code base就可以進
- 避免code base越來越亂，越來越難maintain，越來越想打掉重來
我自己review的重點
- 目標功能合不合理
- 其實開ticket與前期討論時應該就要做好
- 是否達到目標功能
- 整體架構是否合適並簡單明瞭
- 各component間的介面完善且清楚
- 各component各司其職，盡量減少耦合度
- 實作的細節:
- 不硬性規定developer 的寫法，但須確保
- 易讀
- 邏輯清晰明瞭，不要用隱晦或容易造成誤解的寫法
- 避免使用特殊tricky 用法
- 例如特殊技巧或特殊compiler特性
- 若真的要用到，需提出討論並做完整的文件與註解
- coding style與設計架構盡量參照原本code base的作法
- 除非是原本不夠好或有瑕疵須改善
- 演算法空間/時間複雜度
- 需跟預想同量級，若超過還是要要求修改做法
- 邏輯上不會出現潛在問題
- deadlock/race condition....
- 需有test code
- 目標是保護自己(擋住別人會害到我的修改)且保護別人(找到這次commit 與未來commit的bug)
- 一定要加unittest，integration test/end-to-end
test…視情況
- 以component被用的角度來測試
- 可能可以發現找出當初設計沒考慮到盲點
- 避免與實作細節太相關，造成以後每次改都要改test code
- test coverage盡量100%
- 確保所有設計實考量到的地方都能被測到
- 沒跑到的地方需要提出討論
- 注意所有的狀況都需檢查結果是否符合預期，否則會變成只是單純增加覆蓋率的無意義測試
- 需有文件
- 除非是refactoring、修改coding style等小改動
- commit message要完整(ref 2)
- 標題簡潔易懂
- 內容來龍去脈解釋清楚，尤其是為了特殊時空背景而改的東西
- bug id 或是ticket一定要標示清楚
- 親自測試感受一下
其他
- 最終目標: 讓code base越來越好
- comment
- 對事不對人，充分給予說明、參考資料
- 保持developer積極性
- 盡快response，避免developer倦怠
- 不一定要全部看完，有疑問或看到問題點就提出
- 不影響準則的地方尊重developer，不要卡著
- 單純建議，不影響整體的comment加上"NIT:"
- 若覺得有必要就再開ticket要求做
- 鼓勵developer 寫得好的地方
沒有留言:
張貼留言