訊息交易的抽象化思考

在〈開發者的 common sense〉的留言中,同人看到一些網友的批評。我發現這些批評顯示了有些開發者不擅於抽象化思考,而習慣於用經驗法則來取代思考。然而,誠如 Brooks 所言:「軟體的本質是複雜的,而不是偶然發生的」對治複雜度本來就是開發者的天職,而軟體開發的抽象化思考則是其用以統理複雜度的利器。由此看來,那些網友的批評著實令人為他們捏一把冷汗呀。

從路邊的垃圾桶與路人的留言,我們可以發現他們弄錯 common sense 的意思。他們認為 common sense 不能一概而論,因為每個人的 common sense 都不同。但這樣的觀點令人感到疑惑,如果每個人的 common sense 都不一樣,所以無法一概而論,那這種 common sense 還能叫做 common sense 嗎?

到底他們觀點上邏輯的矛盾,問題是出在那裡呢?同人認為問題並不是開發者的 common sense 不存在,而是忽略了開發者應該將經驗化成一般性的通用概念。舉例來說,軟體工程領域本身就是從實務發展出來的理論,其中許多概念就是開發者必須知道的 common sense,對開發者來說是合理的知識,也是他們都知道、無須解釋或加以論證的常識

由此可知,如果開發者缺乏一般性的通用概念,那他碰到問題就很難舉一反三,自然也就難以掌握重點,而只能依據表相來處理問題,往往使得問題變得更複雜。oofunp 的留言就很像欠缺概念思考的開發者常見的反應,一開始以自己熟悉的技術來看問題,最後才發現自己對問題的理解是錯誤的。尤其「以為抽象化是將資料庫定義抽象化」的想法,更是整個弄錯抽象化思考的意義,結果最後他還是誤解了業務規則的意思。

同人前一篇文章所提到的業務規則,並非來自技術領域上萬用的設計,而是對問題領域經過抽象化思考後,所萃取而得到可以解決業務需求的重要概念。顯然 oofunp 的誤解是以技術的角度來看待抽象化思考,才會產生嚴重的觀念混淆。事實上,抽象化思考重視的不是技術實作,而是如何從實際問題當中萃取出重要的抽象概念,以增進我們對問題領域的瞭解,才能採用最適當的技術來開發軟體系統。

此外,過份強調技術經驗而輕忽概念性思維的開發者,很容易表現出自己對問題的盲目。就像 X files 留言的批評一樣,責怪同人沒有交待清楚是 XML 格式的問題,直到別人提出質疑才說明與列出參考文獻,認為同人缺乏部落格文章寫作的 common sense。但我的文章已經很清楚地提到是有關「交易訊息」語法的問題,難道他不瞭解交易訊息是 XML 技術的一般化抽象概念表述嗎?XML 只是實現交易訊息概念的一種技術,用以解決跨系統整合的問題。如果他要看到 XML 字眼才知道是訊息格式的問題,那改天換了另一種交易訊息的實作方式,我想大概他腦筋又要轉不過來了吧。

以上網友的三種批評,表面上看起來好像是不同的問題,但其背後都存在同樣的本質,那就是從交易訊息的問題中可見一斑,他們無法以抽象性思考來看待軟體開發的問題。但為什麼開發者需要抽象化思考呢?可能有人會認為,只有 OOA、OOD、或是 OOP 才會需要抽象化思考,不用物件導向的開發典範,應該不需要抽象化思考。其實這樣的觀念是錯誤的,不管我們採用什那一種開發典範來開發系統,抽象化思考都是必備的能力,只是不同的開發典範需要不同的抽象層面。

世紀末軟體革命復刻版的圖像 抽象思考本來就是人類本能的思維能力,讓我們可以因應變化掌握事物的核心關鍵。這正是《易經繫辭》所言「一陰一陽之謂道,繼之者善也,成之者性也。仁者見之謂之仁,知者見之謂之知,百姓日用而不知。故君子之道鮮矣」的道理,我們常在不知不覺中運用抽象化的概念。最近看到《世紀末軟體革命復刻版》說得好,從小我們就具備了抽象的思考能力,我們可以把我們所關心的特性,從事物中「抽」出來,看出一些形而上、感官之外、富於意義的特性來。

這本書還提到有關抽象化思考的一個重點,事物的意義是針對問題的需要而來。世間事物的特性多到數不清,但藉由抽象化的過程,我們可以把它抽象化為只剩下一些我們需要的特性。我們只要掌握這些關心的特性,就可以讓世間的事物更容易處理。例如一般人所知道的「冰」,在愛斯基摩人眼中卻可分類為十幾種,只因為需要不一樣;我們只要知道冰的概念就行了,但愛斯基摩人對於冰的用處有許多,所以需要更細膩冰的分類。因此,因應需要的不一樣,抽象化思考的結果也會有所不同。

讓我們回到訊息交易系統的開發,抽象化思考通常被稱做資訊隱藏,萃取最有意義的資訊,並去除其它不必要的資訊。以欄位內容取值為例,空白或是空值都只是眾多可能參考欄位內含值的一種,不論空白與否,都不影響系統實際運作的處理程序,因此空白或空值與否的資訊,對系統並不重要應予以略除,這是屬於語法層次的抽象化思考。

當然在實際業務的需要上,空白或空值可能會有特殊的意義,但那並非欄位取值過程本身應該處理的問題,而是由取值後續的檢核資料合理性的規則來處理,這是屬於語意層次的抽象性思考。雖然為了系統執行效能的考量,語法與語意可能會寫在同一支程式或程序當中。但以程式的設計概念來看,因為技術實作的因素混淆語意與語法,而破壞設計概念的整體性,則是無異於自廢武功而使軟體品質問題層出不窮

相信沒有人會否認良好的設計概念應該是「分而治之」,我們在某些訊息交易的標準中,也確實看得到語法與語意分而治之的例子。例如一些 EDI 的訊息標準會以 MIG(訊息建置指引)來規範交易訊息格式,包括欄位的強制性、可重覆出現的次數、欄位可能的內含值來代表訊息的語法,而且多半是通行於相同功能領域的共通語法。而對於相同功能領域不同的交易,則會以 SIG(系統建置指引)來規範特定交易的訊息語意,用來關聯到實務上的業務規則。

早年的 EDI 訊息交易的系統,很多都不是用物件導向的方法所實作出來的,但其系統結構卻與物件導向的抽象化思維不謀而合,這代表什麼呢?同人還是喜歡引用《易經繫辭》的道理,正是「天下事一致而百慮,殊途而同歸」、「易窮則變、變則通、通則久」,事物的核心本質本來就存在,只在於我們如何找出有意義的概念出來,並且加以演化而讓系統不斷進展,重點還在於我們懂不懂得抽象化思考呀。

Please follow and like us:
分類: 分析設計建模, 品質文化, 問題解決, 思考, 易經思維, 生活感觸, 編程技巧, 設計原則。這篇內容的永久連結

在〈訊息交易的抽象化思考〉中有 9 則留言

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *