排出PL/SQL最佳操作規(guī)程優(yōu)先次序加以應(yīng)用
2024-07-21 02:34:34
供稿：網(wǎng)友
排出PL/SQL最佳操作規(guī)程的優(yōu)先次序并加以應(yīng)用，完善新舊應(yīng)用程序。
為開發(fā)人員提出一個"該做什么"和"不該做什么"的列表并不困難。但是，這個列表很輕易讓人完全不知所措，因?yàn)椋╝）記住所有的最佳操作規(guī)程可能很難，（b）實(shí)施最佳操作規(guī)程可能是個挑戰(zhàn)，（c）確定一個團(tuán)隊的開發(fā)人員是否真正遵循這些最佳操作規(guī)程可能很麻煩。
任何一個開發(fā)機(jī)構(gòu)所面臨的挑戰(zhàn)都是跟蹤和應(yīng)用最佳操作規(guī)程。
本文從實(shí)用角度出發(fā)，探討了應(yīng)用排出優(yōu)先次序的最佳操作規(guī)程列表的幾種方法，然后論證了一些關(guān)于代碼是否遵循一系列建議的操作規(guī)程的自動分析方法。
將最佳操作規(guī)程銘記在心
盡可能地采用最佳操作規(guī)程，并以可重用代碼塊的方式來加以實(shí)施，如通用錯誤處理包。然后只需對開發(fā)人員進(jìn)行培訓(xùn)并說服他們使用這些組件，他們便會自動遵循這些最佳操作規(guī)程。
請思考代碼清單1中的代碼。這是一種相當(dāng)?shù)湫偷腻e誤處理邏輯：我要精確地說明我將如何完成這項(xiàng)工作，包括將信息輸出到一個數(shù)據(jù)庫表。代碼中存在著一個重大問題，即：向日志表中插入數(shù)據(jù)的INSERT語句的執(zhí)行變成了業(yè)務(wù)處理的一部分。回滾之后，日志會丟失。 我實(shí)在是應(yīng)該利用自主事務(wù)處理方法啊！
不過，我不會逐一修改這些處理程序段，我會構(gòu)建一個錯誤處理包，然后將它應(yīng)用于每個處理程序段。代碼清單2給出了這類程序包的一個簡單示例的清單。代碼清單3說明了此程序包在異常程序段的應(yīng)用方法。
有了標(biāo)準(zhǔn)的錯誤處理包，你無需再憂慮如何向日志輸出信息，也不必采用任何措施將異常程序段輸出至該封裝塊。錯誤處理包會根據(jù)為該應(yīng)用程序所定義的標(biāo)準(zhǔn)，完成這些所有工作。你可以大大縮短編寫異常程序段所需的時間，而且你的代碼會遵循團(tuán)隊所定義的最佳操作規(guī)程，你也不必考慮這些最佳操作規(guī)程是什么。
當(dāng)然，通用的可重用包不可能照顧到應(yīng)用程序開發(fā)的方方面面。你仍需編寫大量的常規(guī)代碼，而且還要注重這些PL/SQL代碼行的最佳操作規(guī)程。因?yàn)楦櫵凶罴巡僮饕?guī)程比較困難，所以必須排出它們的優(yōu)先次序。
為新應(yīng)用程序排出操作規(guī)程的優(yōu)先次序
并非所有的最佳操作規(guī)程都彼此相當(dāng)。有些對代碼整體結(jié)構(gòu)、可讀性和可維護(hù)性的影響非常大。其他的最佳操作規(guī)程對代碼影響要相對小一些。
不是要努力記住所有的最佳操作規(guī)程或強(qiáng)迫開發(fā)人員遵循所有這些策略，而是要提出一個最佳操作規(guī)程優(yōu)先次序列表。要確定哪些是要遵循的最重要的最佳操作規(guī)程，還要確定如何遵循。然后創(chuàng)建一個短小而簡單的列表，開發(fā)人員可以將它貼在計算機(jī)上或四周，以便非常方便地、經(jīng)常地提醒他們。
在此我提出一些建議，用于最佳操作規(guī)程優(yōu)先次序列表項(xiàng)和以下兩種情況：新應(yīng)用程序的開發(fā)和現(xiàn)有或原有應(yīng)用程序的維護(hù)。
在構(gòu)建新應(yīng)用程序時，你完全有可能把它做好。最佳操作規(guī)程的主要側(cè)重點(diǎn)應(yīng)放在整體代碼結(jié)構(gòu)和可讀性上，同時要給出一定數(shù)量的要害性能增強(qiáng)器的提示。由于篇幅限制，我無法非常具體地深入探討這些最佳操作規(guī)程列表的所有主題。在以前的Oracle雜志和OTN文章中，我已經(jīng)論及了其中的一些主題，在我的《Oracle PL/SQL最佳實(shí)踐》一書中對其他的主題進(jìn)行了討論。我對新應(yīng)用程序最佳操作規(guī)程列表項(xiàng)的建議如下：
不要編寫SQL。當(dāng)你需要某些數(shù)據(jù)時，不要編寫SELECT INTO語句，而應(yīng)調(diào)用一個能提取數(shù)據(jù)，并將所有標(biāo)準(zhǔn)的錯誤處理和優(yōu)化邏輯都隱含在其中的函數(shù)。使用能處理大多數(shù)SQL需求的綜合"數(shù)據(jù)封裝包"會更好。
Oracle設(shè)計器可生成表格API（TAPI）包。也可以用PL/Generator生成這些包，PL/Generator是Quest軟件公司提供的一個免費(fèi)實(shí)用程序，可在www.stevenfeuerstein.com/puter/gencentral.htm獲得。還可以使用Swyg，這是我在www.Swyg.com上提供的一個新產(chǎn)品。
帶有特定SQL最佳操作規(guī)程列表提示的列表應(yīng)包括以下項(xiàng)目：
編寫微小的代碼塊。 在Oracle雜志2003年11／12月號中，我強(qiáng)烈建議代碼的執(zhí)行部分長度不應(yīng)超過50或60行。這樣隨著時間的推移，該代碼的閱讀和維護(hù)會輕松許多。在新代碼中遵循這一最佳操作規(guī)程的最佳方法是采用自頂向下的設(shè)計方法，同時采用局部模塊或嵌套模塊。OTN上我的《代碼檢查》一文（位于otn.oracle.com/pub/articles）具體地介紹了這種方法。
帶有特定代碼塊提示的列表應(yīng)包括以下項(xiàng)目：
從BEGIN到END的代碼不超過50行。
創(chuàng)建局部過程和函數(shù)以隱含邏輯。
將所有的公式和商務(wù)規(guī)則都隱含在函數(shù)當(dāng)中。
首先編寫單元測試。開始編寫代碼之前，應(yīng)先設(shè)計用于測定該代碼能否運(yùn)行的測試。假如一直等到寫完程序之后才設(shè)計"測試"，你會下意識地只編寫你完全知道其（或希望的）功能的條件和邏輯"測試"。假如首先編寫測試，你就可以專注于代碼庫的整體設(shè)計及與單個程序的接口。
當(dāng)然，編寫測試代碼本身就是一個非常大的話題，自然也是一個非常大的挑戰(zhàn)，但是我建議利用Ounit和utPLSQl：面向PL/SQL開發(fā)人員的免費(fèi)的、自動化單元測試軟件，可在www.ounit.com網(wǎng)站獲得。開誠布公的講，是我設(shè)計了這兩個工具，而且其總開發(fā)師也是我。
你的列表應(yīng)考慮到這些測試項(xiàng)：
編寫代碼之前編寫測試實(shí)例。
編寫測試實(shí)例來驗(yàn)證錯誤報告。
編寫測試實(shí)例來驗(yàn)證成功的改進(jìn)。
利用自動框架（Ounit和utPLSQL或自編的實(shí)用程序）來執(zhí)行測試實(shí)例。
為維護(hù)排出操作規(guī)程的優(yōu)先次序
許多PL/SQL開發(fā)人員將相當(dāng)一部分時間都用在了維護(hù)現(xiàn)有應(yīng)用程序上。 這種工作往往難度很大，輕易使人灰心，因?yàn)樵S多代碼寫得都很差，難于理解，而且絕大部分都沒有經(jīng)過測試。 幾乎每個應(yīng)用程序都有一個"黑洞"程序： 那些毫無結(jié)構(gòu)化可言、使每個人都望而卻步的極大的代碼塊。 假如在第255行作一下修改，那么整個程序中可能會引入25個錯誤。 還沒有辦法讓人真正知道所做修改對整個代碼會產(chǎn)生什么影響，因?yàn)檫€沒有適用的回歸測試。
如需將最佳操作規(guī)程用于現(xiàn)有的應(yīng)用程序，應(yīng)當(dāng)采用遞增和迭代的方式進(jìn)行修改。 僅僅因?yàn)楝F(xiàn)行的生產(chǎn)應(yīng)用程序能夠編寫得更好，開發(fā)經(jīng)理就支持對其進(jìn)行修改是比較困難的。
假如必須打開黑洞程序，你應(yīng)當(dāng)應(yīng)用要害性的最佳操作規(guī)程，而且其應(yīng)用應(yīng)當(dāng)有限。 以此方式進(jìn)行修改的最佳操作規(guī)程列表的一些建議如下：
編寫一個回歸測試。這可能是一項(xiàng)既費(fèi)心又費(fèi)力的工作，但假如你對維護(hù)一塊代碼還抱有一線希望，也還有信心，你就必須完成這項(xiàng)工作。開始維護(hù)現(xiàn)有程序之前，應(yīng)盡可能多地思考能夠驗(yàn)證程序工作情況的那些測試條件。在一個測試包中執(zhí)行這些條件，運(yùn)行該代碼，并確定該程序運(yùn)行是否正常。接下來，在進(jìn)行修改時，可以重新運(yùn)行這一測試，并確保沒有引入任何錯誤。此外，Ounit與utPLSQL此時也可以大顯身手。
構(gòu)建隱含功能可識別區(qū)域的局部模塊。 程序的執(zhí)行部分可能長達(dá)1000行。從該執(zhí)行部分的頂部開始，向下通讀整個代碼。假如可以確定其中的20、30或100行代碼是用來驗(yàn)證參數(shù)和初始化數(shù)據(jù)的，就可以將所有這些代碼行從該執(zhí)行部分取出，并代之以一行代碼：
initialize_data;
然后，將這些行移至聲明部分，其中的局部過程上下文如下：
PROCEDURE initialize_data IS
...all that code...
END initialize_data;
隨著時間的推移，這個不可讀的執(zhí)行部分將變得越來越小、更易于訪問。
從性能的角度來看，應(yīng)查找可應(yīng)用FORALL和BULK COLLECT的區(qū)域，幾乎所有情況下使用它們都能大大提高性能。找出程序中所有的DML語句。假如它們出現(xiàn)在任意的一種循環(huán)內(nèi)部（游標(biāo)或其他類型），則將所有的DML邏輯取出，代之以過程調(diào)用；將此邏輯作為一個局部模塊移至聲明部分；然后將其改進(jìn)以進(jìn)行批量處理。
驗(yàn)證是否遵循最佳操作規(guī)程
你要購買書籍、編寫列表、傳授最佳操作規(guī)程。接下來是團(tuán)隊中的所有開發(fā)人員編寫他們的代碼。即使是對于已經(jīng)排出優(yōu)先次序的建議，要讓每個人（無論誰）都記住并遵循也不太可能。
因此你必須決定：是讓這些最佳操作規(guī)程都變?yōu)榭扇芜x的（這意味著其中的大部分都將被忽略），還是努力確保人們都遵照它們行事。
我建議你應(yīng)該找出用于檢查團(tuán)隊開發(fā)人員所編代碼（或者你自己編寫的代碼，因?yàn)榧词褂辛俗詈玫挠媱潱阋矔龅嚼щy，你必須做對每一件事！）的方法。驗(yàn)證是否遵循最佳操作規(guī)程的兩個最好方法是代碼復(fù)查和代碼分析。
仔細(xì)檢查代碼！未經(jīng)不同的開發(fā)人員（除代碼編寫者之外的人）檢查，任何代碼都不能移交給質(zhì)保人員（QA）或者運(yùn)行于生產(chǎn)環(huán)境中。代碼復(fù)查可以表現(xiàn)為從極限編程（Extreme Programming）的結(jié)對編程到簡單的伙伴系統(tǒng)（Oracle雜志2003年11／12月號進(jìn)行了探討）等多種形式。
在結(jié)對編程時，任何程序員都不是獨(dú)自編寫代碼。每個工作站前面都坐著兩個人，代碼的每一行都由兩個人進(jìn)行檢查和評估。顯然這是一種極端的作法，盡管這樣可以提供巨大價值，但極少有開發(fā)團(tuán)隊這樣做。
有些機(jī)構(gòu)具有正規(guī)的代碼復(fù)查過程，所有的開發(fā)人員都將其代碼提交給其他所有開發(fā)人員并獲得反饋意見。其他機(jī)構(gòu)采用一些非正規(guī)方法：高級程序員只負(fù)責(zé)代碼的整體情況，有時也會停下來檢查其他開發(fā)人員的代碼并提出建議。
用SQL分析代碼。假如你開發(fā)的是大型應(yīng)用程序，當(dāng)然就會有幾萬行的代碼。復(fù)查每一行代碼可能完全不切實(shí)際。在這種情況下，自動化的代碼分析非常重要。 還好，PL/SQL語言可用于這種分析。
無論何時需要編譯程序，Oracl
