close
CheckItems
| 重要等級 | 人工/自動 | 分類 | 項目 | ||
| 完整性 | CM | ||||
| H | M | CM01 | 必須實現SDD | ||
| M | A | CM02 | 無引用的變數或方法必須刪除 | Findbugs 可協助 | |
| 一致性 | CS | ||||
| M | A | CS01 | 風格必須一致 | 由 CheckStyle 檢查或 使用 IDE 的 Formater 格式化 | |
| 正確性 | CR | ||||
| M | A | CR01 | Class 與 Public 方法, 參數必須有注釋 | 由 CheckStyle 檢查 | |
| H | M | CR02 | 方法名稱, 註解內容與實作責任必須一致 | ||
| H | A | CR03 | 必須關閉已開啟資源 (如, File) | Findbugs 可協助 | |
| H | M | CR04 | 指標釋放後必須設定成空指標 | ||
| H | A | CR05 | 實作出的模組相依關係必須與設計一致 | JDepend 可協助 | |
| 可修改性 | MD | ||||
| M | M | MD01 | 方法中必須只能有一個 return | ||
| 可理解性 | UN | ||||
| H | M | UN01 | 方法命名必須有意義 | ||
| H | M | UN02 | 參數命名必須有意義 | ||
| 健壯性 | RB | ||||
| H | M | RB01 | 方法必須採取防禦式編程 (考慮 Value 的合理性, 上下界, 量的合理性) | ||
| H | A | RB02 | 數值運算必須有考慮到"被零除"的情況 | Findbugs 可協助 | |
| H | M | RB03 | 若有使用數值判斷, 必須考慮到數值得精確值與變數宣告的型態所帶來的不確定性的影響 | ||
| H | M | RB04 | 必須考慮到取得的資料筆數會"非常多"的情況 | ||
| H | M | RB05 | 不可在集合迴圈中變更集合的內容 | ||
| H | M | RB06 | 對於各層級發生的異常或錯誤必須有適當的處理 | ||
| H | M | RB07 | If 判斷式必須完整; 對於非預期的 else 必須有適當的處理 | ||
| 可理解性 | UD | ||||
| M | A | UD01 | 不可存在 Magic String 與 Magic Number | 由 CheckStyle 檢查 | |
| H | M | UD02 | If 判斷式必須有意義 | ||
| M | M | UD03 | log 的等級與描述內容必須合理; 描述內容必需可理解; 加註的內容請見 log 檢查說明 | ||
| 可追溯性 | TA | ||||
| M | M | TA01 | 必須有紀錄程式碼異動歷史 | ||
| 可驗證性 | VR | ||||
| M | M | VR01 | 代碼的實現技術必須便於測試 | 定義於開發規範中 |
重點
| 目的: 提早發現缺失, 降低錯誤或不良的設計與開發 |
| 1. 傳達好的設計概念與品質的要求 |
| 2. 設計到開發零誤差. |
| 培養參與 Review 的同事也能夠有相同的理念與標準並且能堅持. |
| 參與者的心情應該要像安熙教練與櫻木花道的一萬顆射籃特訓一樣. |
| 發生頻率: 前一天如果有產出, 則隔天的早上就進行. |
| 什麼時候可以停止: 參與者皆合意時. |
| 各階段反覆次數: SG1 最多 3 次. SG2 最多 3 次. SG3 最多 3 次. |
| Review 的各個階段: |
| 階段一: 檢視類別相依, 責任與偽碼 |
| 重點: 是否違反相依關係? 類別責任定義與偽碼描述是否合適? (請閱讀 Code Complete, GRASP 模式) |
| 1. 類別是否有破壞模組相依關係 |
| 2. 類別責任是否滿足 GRASP 模式 |
| 3. 是否有滿足系統與功能規格. |
| 輸入: 審視項目, 設計規格書, 模組關係圖, 主要類別責任說明, 參與審查的程式碼, 上次缺失清單 |
| 輸出: 缺失清單 |
| 階段二: 檢視 Method責任與偽碼 |
| 重點: 是否滿足 GRASP 模式? |
| 1. 類別責任是否滿足 GRASP 模式 |
| 2. Method 命名是否有意義? 是否與偽碼呼應? |
| 3. 偽碼的描述是否足夠? |
| a. 若有對資源或系統行為、功能的假設, 則要說明之. (見 Code Complete) |
| b. 若有因外在的原因而限制本身的作業, 則要說明之. (見 Code Complete) |
| c. 若有輸入, 則要有 "檢查參數" 敘述. |
| d. 必須考慮異常, 並說明處置方式. |
| 輸入: 審視項目, 模組關係圖, 參與審查的程式碼, 上次缺失清單 |
| 輸出: 缺失清單 |
| 階段三: 檢視 程式碼 |
| 重點: 類別是否有違反相依關係? Method 程式碼是否有滿足偽碼 ? |
| 1. 演算法是否適當? 考慮速度或資源控制. |
| 2. 是否滿足偽碼? |
| 3. API 使用是否正確? |
| 4. 變數命名是否有意義? |
| 5. 變數宣告位置是否滿足『靠近原則』? |
| 輸入: 審視項目, 模組關係圖, 參與審查的程式碼, 上次缺失清單 |
| 輸出: 缺失清單 |
階段一(SG1): 檢視類別相依, 責任與偽碼
階段二(SG2): 檢視 Method 責任與偽碼
階段三(SG3): 檢視 程式碼
Review logs
| ID | 預計出版版號 | Review Date | Author | Reviewer | LOC | Review時間(first hrs) | 總Review次數 | 出版後異常數 |
Item logs
| Review ID: | |||||||||||||
| CM01 | CR02 | CR04 | MD01 | UN01 | UN02 | RB01 | RB03 | RB04 | RB05 | RB06 | RB07 | UD02 | UD03 |
文章標籤
全站熱搜
留言列表
軟體世界 
