作業: 審查程式碼
這項作業說明如何審查程式碼來驗證實作。
規範: 實作
關係
角色主要執行者: 其他執行者:
輸入強制: 選用:
輸出
流程用法
步驟
一般建議
目的 各次審查的一般建議。

當您建置高品質的軟體時,審查實作是用來補充其他品質機制,例如編譯、整合和測試。在審查實作之前,請編譯它,並利用程式碼規檢查程式之類的工具來擷取儘可能多的錯誤。請考慮使用允許程式碼視覺化的工具。如果是利用執行時期錯誤偵測工具來執行程式碼,也可能在實作審查之前,偵測和消除其他錯誤。

審查實作的好處如下:

  • 既強制也鼓勵專案採用共用的程式撰寫風格。審查程式碼是讓成員遵循程式設計準則的有效方法。為了確保這一點,審查所有作者和實作者的結果,比審查所有程式碼檔案重要。
  • 找出自動測試找不到的錯誤。實作審查會擷取到不同於測試審查的錯誤。
  • 使每個人分享知識,以及將老手的知識傳給新人。

您可以利用許多技術來審查實作。請使用下列項目之一:

  • 檢驗。這是正式的評估技術,它會詳細檢查實作。檢驗被認為是收獲最多的審查技術,不過,它需要訓練和準備。
  • 輕鬆演練。這是實作作者帶著一或多位審查人員經歷實作的評估技術。審查人員會提出關於技術、樣式、可能的錯誤、違反程式碼撰寫標準等方面的問題和意見。
  • 閱讀程式碼。由一兩人來閱讀程式碼。當審查人員備妥之後,他們可以開會提出意見和問題。不過,這個會議可以省略,審查人員可以用書面形式,將他們的意見和問題提供給作者。建議您利用閱讀程式碼來驗證小型的修正,以及作為一項「健康檢查」。

這個角色的技術需求類似於實作者角色的技術需求:扮演這個角色的人通常會被視為審查的程式碼所用之程式語言的專家。在大部分專案中,是由實作小組的資深程式設計師來扮演這個角色。

另請參閱技術:審查

建立實作的核對點
目的 建立審查實作的核對清單。 


本節提供審查實作的一般性核對清單,只是作為審查尋找之項目的範例。程式設計準則應該是程式碼品質的主要資訊來源。

一般

  • 程式碼遵循程式設計準則嗎?
  • 程式碼會自行產生文件嗎? 有可能因閱讀程式碼而瞭解程式碼嗎?
  • 程式碼規則檢查偵測到所有錯誤嗎?使用了執行時期錯誤偵測工具嗎?

備註

  • 備註是最新的嗎?
  • 備註清楚而正確嗎?
  • 如果程式碼有了改變,備註很容易修改嗎?
  • 備註焦點是說明為什麼,而不是如何做嗎?
  • 所有驚奇、例外情況和暫行解決錯誤都有備註嗎?
  • 每項作業的用途都有備註嗎?
  • 每項作業的其他相關事項都有備註嗎?

程式碼

  • 每項作業都有能夠描述作業用途的名稱嗎?
  • 參數有描述性名稱嗎?
  • 每項作業的正常路徑與其他異常路徑有明顯區別嗎?
  • 作業是否太長?能不能將相關的陳述式擷取到私密作業來簡化這項作業?
  • 作業是否太長?能不能減少決策點的數量來簡化這項作業? 決策點是程式碼可以採取不同路徑的陳述式,如 ifelseandwhilecase 陳述式。
  • 巢狀迴圈已減到最少嗎?
  • 變數妥善命名了嗎?
  • 程式碼直接而明確嗎?它是否避開了「聰明的」解決方案?
準備審查記錄以及產生問題文件
目的 產生審查結果的文件。
確定已產生所識別之問題的文件。 


在每項審查會議之後,會議結果必須記錄在審查記錄中。另外,問題也必須記錄在變更要求中(最後指派給某個人來引導解決)。