讀到本書這一段時，感覺非常特別：一方面是這個「搞資料庫的」作者在本書中好多地方，用特別的講法切中程式設計的中心概念，相當引人反思：例如，他說：「如果用 C 和 Java 這種 procedural 語言寫程式，是叫使用者幫忙把事情做好，而 declarative 語言則是叫系統幫自己做事情 (SQL 也算是 declarative 語言，但這一般是指像 Prolog 的邏輯風格的語言，或是像 LISP 和 CLIPS 這種函數風格的語言) 。程序就是安排使用者去走哪些他們該走的流程。宣告式語言則是只把自己的函數寫好並擺著，等使用者他們需要的時候過來呼叫，系統就會動起來。另一方面，這本在 2000 年出版的書籍，主題是 Business Rule ，內容卻提到要將過去寫程式的思考方式做一層翻新。書中又隱約透露出，在電腦程式設計中， declarative 風格的語言向來不佔一席之地，而許多數學家和電腦理論家都努力推動這種程式語言，以及推動它們的實務工作。
(自訂標題) 寫程式：從「如何」到「什麼」
於是，一以貫之，歷史的走向全然遠離程序式、而趨於宣告式，也就是從「如何」到「什麼」。「如何」就是逐步說明該如何做工作；「什麼」就是說明該做什麼工作。那麼，為什麼這種趨勢是個大好消息？答案是：宣告式 (什麼) 意思就是要系統做事；程序式 (如何) 意思則是要使用者進行工作。用一句話解釋，就是：
宣告式比程序式更好！
所以，如果我們能把全部我們的程式工作都用程序式的，不是很好嗎？這樣的需求已經很多很多年前就是大家的目標了。 (如果時間沒更早，大家已經遠從 1970 年開始談論關於「完全可編譯並可執行的規範書」了。) 換句話說，如果我們能簡單地明確規定我們的程式，並讓系統把這些規格編譯成可執行碼呢，不是很棒嗎？
好，我們往下走，如以下所見。
那好處非常明顯：當然是生產力。工作更容易也更簡單地完成了。而且跟著有許多附帶的利益，特別包含了各種的獨立性。有一種令人熟悉的獨立性是「資料獨立性」，它使我們改變 (舉例是為了效率因素而改變) 資料實際儲存在磁碟的方式，而不必做哪些對應的動作，改變用到這些資料的程式。也有許多其他種類的獨立性，其中有些，在本書後段還會看到。所有獨立性的好處是，那使程式對某種改變免疫，特別是對某種商務上的改變更是這樣。這是好事，因為，如果們所知：生命中惟有一件恆定的事，就是改變。
但是，程式到底是什麼？很顯然，程式是某件商務功能的實現：例如，「添入一項訂購物品資料」、「刪除一項訂購物品資料」、「修改某項料件的庫存數目」。一般是程式都牽涉到三種元件：
- 展現方面的元件
- 資料庫方面的元件
- 由商務功能本身定義出來的元件
展現方面的元件是必須處理終端使用者介面的元件，包括工作有幫使用者顯示表單、從使用者接收所填的資料、顯示錯誤訊息、產生列印的輸出等等。資料庫方面的元件應該做粹取和更新資料庫的資料，以因應使用者的請求，以及因應使用者在表單的填入資料 (那些表單是與資料庫 server 互動的部份，又稱為 DBMS 、資料庫管理系統) 。最後，稱為「由商務功能本身定義出來的元件」可能要想成是專屬於應用程式的；那些是指定做真正處理的程式，被做出來要實現商務函數，或是，換句話說是有效地實作商務策略和實行的程式。
現在，這三項之中，前二項已經在某些重要時刻大量地自動化了。程式開發人員不再寫細微的程式碼來處理螢幕繪圖，或找到螢幕上的表單修改之處──只是呼叫內建的展現服務來搞定那些工作。同樣地，他們也不必寫細瑣的程式碼來管理磁碟裡的資料。他們只是呼叫某些資料庫服務來做好那些工作。但是第三個元件呢，由商務功能本身定義出來的元件，那些東西還是大部份用手工做到，意味了有人還是照樣寫一大堆程序式的程式。而且，當然啦，那就是個毛病了 ...... 是把第三元件自動化的時刻了！而那真的就是全部與「商務規則」相關的事：把商務處理工作自動化。
接下來的做個像在信封背面做分析那樣的粗略計算，可能對提供我們所談論的重點的一些想法有所幫助。典型的資料表可能需要五頁相關的程序式程式；標準資料庫 (不大的資料庫) 可能包含 100 張資料表；好的程式刻工手可能每天可以產生一頁程式碼。淨額是： 500 人日 (譯註：人日是單位詞。《人月神話》也提到這樣的單位，將人力數目和工作時間的乘積當做計量單位。) 造就一套手工系統。相反地，簡單地規範定義同樣的系統，是五到六週的工作；而如果這些規範都可以執行，我們就有效地把開發時間減少一個級數 (譯註：級數， order of magnitude ，簡單說，是二個指數乘冪數值的差距：例如， 1000 比 100 多一個級數，因為 1000 是 10 自乘三次，而 100 是 10 自乘二次。) 。
No comments:
Post a Comment