PL/SQL 開發實戰心法：命名規範、少寫 SQL、模組化與同儕審查

大多數 PL/SQL 開發者獨自在工位撰寫程式，缺乏正式 Code Review 與自動化測試。不改變團隊流程，只要改變「個人編碼習慣」，即可顯著提升程式品質。以下四大原則經實戰驗證極具效力。

1. 視命名規範為生命線

建立專案專屬縮寫字典（如 SF=核心框架、SM=中繼資料、SG=產生器…），所有套件、程序、變數、游標皆依規範命名。好處：

• 可預測性強，SQL*Plus 腳本可自動產生安裝/部署/測試腳本。
• 閱讀、搜尋、重構效率大增。

2. 戒除「到處寫 SQL」惡習

PL/SQL 內嵌 SQL 雖方便，卻導致：

• 同一邏輯 SQL 散落各處，難以優化、維護。
• 硬解析增加，共用游標機制失效。

對策：將 SQL 封裝於 套件函式/程序 或 View，業務邏輯層僅呼叫 API。例如 pkg_employee.get_salary(p_emp_id) 取代散落的 SELECT salary …。

3. 執行區塊保持精簡——拒絕義大利麵條式程式碼

• 單一程序/函式不超過 50 行（含註解）。
• 將驗證、計算、資料存取、日誌、例外處理拆分為私有子程序。
• 主流程僅呈現「做什麼」，細節委派給「怎麼做」。

4. 找一位 Code Buddy 互相把關

即使團隊無正式 Code Review，私下找一位同事定期交換審視 30 分鐘，專注於：

• 命名是否符合規範
• SQL 是否封裝妥當
• 例外處理是否吞沒錯誤
• 邊界條件測試是否完整

「紀律勝過天賦。」將上述四點內化為肌肉記憶，你的 PL/SQL 將更健壯、可維護、高效能。