提高編寫PL/SQL代碼數量及品質的四個簡單易行指導方針
我從1990年就開始編寫PL/SQL代碼。這意味著我已經編寫了幾萬行的軟體代碼,但我確信,其中的絕 大多數代碼都非常拙劣,而且難以維護。
幸運地是,我發現找到並遵循編寫出更好代碼的新方法還為時不晚。就是在去年,My Code品質有了 顯著改進;這些改進主要是由於制定了一些簡單的規則,並像紀律一樣加以遵守。
本文為PL/SQL新手及有經驗的開發人員提出了四條建議;遵守其中任何一條,你的代碼品質都會有提 高。這四點建議都採納,你可能會驚奇地猛然發現:你竟然是一個非常好的程式員,要遠遠超乎你的想象 。
所有工作都獨自完成
我們很少有人是孤立工作的;大多數PL/SQL開發工作是在相對較大的機構中進行的。但我們基本上還 是在自己的小隔間裡用自己的裝置獨自工作。幾乎沒有PL/SQL開發小組進行正規的代碼複查或系統測試。
我不可能通過這篇文章改變你們開發小組的基本狀態。因此,我仔細地選取出以下幾點建議。實施其 中任何一點並不需徵得管理員同意。不論你的小組是大是小,都不必讓其中的每個人都贊同這些編碼規 則。你只需按以下建議來改變你的本人的編碼方式:
1. 嚴格遵循命名規範,好像它們就是你的生命支柱。
2. 戒除編寫SQL的嗜好:編寫的SQL越少越好。
3. 使執行部分短小:告別"意大利麵條式的代碼"。
4. 找一位夥伴:非常贊同找個人來監督你的工作。
1. 遵循命名規範
如果你建立並嚴格遵循一套命名規範,特別是對於應用程式組件的,你就可以節省很多時間。
當然,遵循命名規範的想法並沒有什麼新意,你可能已經聽煩了。所以我並不提出什麼宏偉的命名計 劃,而是給出一些非常具體而明確的約定,然後證明這些約定會多麼有用。
前幾個月我一直在為PL/SQL開發人員設計、構建一種新工具。它名為Swyg(可以在www.swyg.com中找 到),可以協助程式員完成代碼的產生、測試及重用的工作。它具有幾個獨特的組件。我為每個組件指定 了一個由兩個字母組成的縮寫名稱,如下所示: SF-Swyg的基礎組件
SM-Swyg的中繼資料
SG-Swyg的產生程式
SL-Swyg的 程式碼程式庫
ST-Swyg的單元測試
於是,我便遵循表1中的命名規範,同時使用這些縮寫。遵循這些約定有什麼好處呢?一般來講,如果 我要求一致的命名規則,我就可以更流暢更高效地編寫代碼。
明確地說,這些約定具有可預測性,意思是說我編寫的SQL程式能產生有用的指令碼。例如,通過使用表 1中的約定,可以產生Swyg中所有基礎包的安裝指令碼。執行這些工作的SQL*Plus指令碼如清單1所示。這類腳 本非常有用,因為它意味著我不必手動維護安裝指令碼。當我向Swyg方案中增加另一個表,並產生一組相關 包時,我只要運行我的指令碼,更新後的安裝指令碼便會跳出來。