程式碼審查的主要目的：將可維護性置於找錯誤之上
程式碼審查的主要目的：將可維護性置於找錯誤之上
程式碼審查作為可維護性的工具
程式碼審查的主要目的在於識別將來難以維護的程式碼。雖然審查者在過程中常會發現錯誤，但將程式碼審查作為主要的找錯機制並不實際，因為僅靠檢視原始碼通常無法保證發現所有錯誤。
當審查者難以理解某段程式碼的功能與實作方式時，這種困難即是該程式碼未來將難以維護的訊號。最有效的修正時機就是在審查過程中，因為原作者仍對實作細節相當熟悉。
「可理解性」指標的實務優勢
將程式碼審查以可維護性為核心，能為審查者設定更可達成且客觀的目標。
- 找錯是開放式的： 要求審查者「找錯」是一項沒有明確成功定義的困難任務。審查者可能花數小時找出三個錯誤，卻仍因漏掉第四個而受到批評。
- 可理解性是二元的： 要求審查者「看能否理解」則是一項直接的任務。成功與否是保證的：審查者要麼理解程式碼，要麼不理解。如果不理解，只需註明哪些部分讓他感到困惑。
超越可維護性：審查的次要好處
雖然可維護性是核心目標，完整的程式碼審查流程仍能為工程團隊帶來多項關鍵的次要效益：
知識傳遞與社會化
程式碼審查充當一道關卡，使程式碼從個別作者的所有權轉移至團隊所有。它確保至少有兩個人了解程式碼庫的每一部分，避免只有單一人掌握關鍵系統運作的「知識孤島」。
指導與標準對齊
審查是教育初級開發者團隊慣例與系統架構的主要管道。資深開發者可以分享專業知識——例如最佳化技巧或函式庫使用方式——並協助作者遵循團隊標準，以防未來出現可維護性問題。
品質管控與風險緩解
雖然不是主要的找錯工具，審查仍充當最後的安全檢查。它能發現自動化測試可能遺漏的「程式碼味道」、安全風險與效能問題。審查也確保測試不只是「綠色」通過，而是真正驗證預期邏輯，而非僅僅鏡像程式碼實作。
反對意見與產業觀點
並非所有工程師都認同可維護性應是主要焦點。討論中呈現了幾種不同的觀點：
- 高保證領域： 在航空航太等領域（例如 DO-178C），程式碼審查往往被倒置，嚴格要求驗證、精確性與符合需求為首要任務。
- 「品質門」觀點： 有人認為程式碼審查是生命週期中最重要的品質管控程序，特別是在需求模糊或缺乏 QA 流程時。在此觀點下，找錯是核心目標，而非次要。
- 自動化的角色： 多數人同意功能正確性應交由單元測試與 CI/CD 流程負責。正如一位貢獻者所說：
"如果主要目的在於找錯，或缺乏錯誤，那就不是審查，而是稽核。"
審查者的最佳實踐總結
為了最大化以可維護性為中心的審查價值，審查者應該：
- 要求說明： 若程式碼段不明顯，請求作者解釋。
- 鼓勵程式內文件化： 當作者在 PR 註解中說明一段令人困惑的程式碼時，審查者應要求將說明移入程式碼本身作為註解，供未來維護者使用。
- 驗證測試覆蓋率： 確保測試涵蓋邊緣案例，且測試真正驗證規格，而非僅驗證當前實作。
- 聚焦模式： 防止「範式腐敗」，確保新變更遵循既定的團隊模式，而不是引入不一致的新格式或結構。