航向新世界

Code Review 是不是多餘的?
如果你是汲汲於賺錢的老闆, 應該覺得這幹麻做, 浪費時間.
如果你跟我一樣是個程式小工, 那麼請跟我一起重視這件事情. 透過這個活動讓我們養成一種正確的習慣.
CodeReview 不用是一群人在房間裡盯著一支程式在指指點點. Review 若讓人覺得沮喪, 最終將淪為形式; Review 應當要讓人覺得有進步, 高興, 可以為其他人的學習典範.

如何讓 CodeReview 可以時常進行?

• 有重點
• 有原則
• 有範圍
• 可快速識別問題

如何知道 CodeReview 有成效?

• Review 項目必須一致
• 問題識別標準必須一致
• Review 活動必須被紀錄
• 上線後與Review相關的異常數必須被 feedback

如何知道可以更換 Review 項目了?

• 個人各項Review項目的缺失數量連續幾次為 0 或達可接受的標準

如何知道可以不用再 CodeReview 了?

• 個人已無須Review的項目
• 產品的被發現的異常數在可接受的範圍內
• 組織禁止 CodeReview

努力讓 Code Review 成為一種內在習慣.

原則:

每次 Inspection Review 時間不超過 60 分鐘
每人每次 Inspection Review 代碼不超過 200 行
KPI: TBD

角色:

Author

提供要Review的程式碼與相關的SDD文件 (標示或說明 Review 的範圍[File或Method])

提供 findbugs 的結果

提供個人的 CheckList

Moderator

Review process 的負責人.

找到合適的 reviewers.

把被文件的給 reviewers.

提供專案的 CheckList

Reviewer

To reads and comments on the code.

To log a Record

CodeReview Activities:

Inspection Review Flow:

Records:

• 預計出版版號
• Review Date
• Author
• Reviewer
• LOC (TBD: Modified Method 的 LOC 或 一支 java 的 LOC)
• Review Items
   -- Number of defects for each item (只紀錄第一次審視發現的缺陷, 不紀錄複審的)
• First Review Time (hrs) (只紀錄第一次審視花費的時間, 不紀錄複審的)
• Total Review Times (複審次數)
• Number of defects of released-related

如何促成改善:

• 透過團隊與個人累積的缺陷紀錄, 提供團隊與個人的改善建議與精進目標.

工具可以協助的事情:

• 計算 LOC
• Review 活動的管理
• 靜態分析

產出資料:

• 更新個人的 CheckList
• 更新專案的 CheckList
• 單次缺陷紀錄
• 歷史缺陷紀錄庫

定義:

• Inspection Rate: kLOC per hour  (若規模不大, 可以直接用 LOC)
• Defect Rate: Number of defects found per hour
• Defect Density: Number of defects found per kLOC (若規模不大, 可以直接用 LOC)
• Effective: TBD