訊息交易的抽象化思考

在〈開發者的 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 則留言

  1. 路人表示:

    「交易訊息」可作為XML 技術的一般化抽象概念表述,但如果系統是以binary stream傳遞交易資料,那交易訊息是否也可以當作此種技術的一般化抽象概念表述?
    我覺得「交易訊息」本身就是不涉底層的一種概念,當有人談到交易訊息的時候,每個人心中可能會浮現不同的實作方式,這邊的實作方法便是在抽象過程中被捨棄的部份,可是在文章中所談論的不是關於「交易訊息」本身的概念,而是一種底層實作技術「XML」。這個時候是不是直接使用「XML」這個詞彙會比使用一個抽象不準確的「交易訊息」好一些?
    最後我覺得在缺乏準確的表達能力時去談論任何抽象概念,只是緣木求魚罷了。

  2. jim yeh表示:

    說實在的,對於以上這種似是而非論調的路人留言,我是愈來願不願意理會了。別的不說,躲在網路暱稱的保護傘後面亂放話,沒有尊重何來對話?更不用說台端不懂裝懂的包裝留言透露著偏見形成對問題的無知,你的說辭只是為錯誤的觀念來自圓其說,根本無須浪費時間來理會它。

  3. 生魚片表示:

    同人說的是一種思維.哲理.典範.生活觀
    卻被硬生生的當作是一種”技術”的謬論….

    或許這也是台灣比較不好的現象…

  4. jim yeh表示:

    Hi 生魚片,

    這些路邊的閒言閒語,我認為正顯露只懂技術而看不到問題的「功能性的盲目」。

    柯維在《第八個習慣》引用美國作家賈德納(John Gardner)說過的話:「大多數有問題的組織是因為滋生出一種功能性的盲目,看不見自己的缺點。它們的癥結並不在於無法解決問題,而是根本看不見問題。」用這句話來看台灣常見的不重視概念,卻充滿技術偏見的現象還真貼切。

    抽象化思考的 common sense,本來就和 XML 技術沒有直接的關係。交易訊息對欄位空白的處理,和你用的訊息格式交換無關。你可以用 flat file、csv file、user define file、EDI、XML、binary stream,甚至是 whatever 的各種格式來傳遞訊息。但不管怎麼傳遞,在概念上的處理都一樣。出現某個欄位,但其值是空白的,那麼系統該如何處理它?

    概念呈現的是問題的本質,而不在技術。技術的好處只在具體化概念。因此,如果開發者看不到概念,我們只好找一個特殊化的技術來舉例說明,幫助他們來體會概念。

    但不知是真的無知,還是刻意扭曲,把技術簡化成問題,真的問題卻視而不見。這只會讓我想到瞎子摸象的故事,瞎子不知大象長得什麼樣子,當他們摸到象腿粗粗的,還以為大象只是樹幹。跟這樣的人論理,還真的只是浪費生命。

  5. 生魚片表示:

    如同絕頂高手,與敵相鬥,看似無劍相擊,但劍卻無處不在,萬物皆可為劍~

    我想很多人還停留在手中有劍,心中無劍的階段…如我也是Orz

  6. jim yeh表示:

    生魚片,其實軟體開發的問題多半不需要太高深的心法。就像交易訊息的問題,區分語意與語法並不那麼困難,而且參考一些標準的最佳實務,可以幫我們找到心中的那把劍。只要我們不執著技術的偏見,願意面對問題多思考,多練習幾次,心中的劍就會慢慢出現。就如同我在〈由招熟漸悟懂勁〉所說的:

    招式的變化在於個人平常願意動手作及努力練習的心得;心法的流露則是懂得在特定的時機及場合採用適合的招式來因應、兩者相互配合才能開發出良好的軟體系統,設計實作系統原來和練功夫一樣。

    「階」字巧妙地說明了心法的加深是需要經驗不斷累積的,每個人會有不同的觀點,所以為避免陷於受限知識框架下,適當的社會化的交流是必要的。「相觀而善謂之摩」,透過相互溝通不同的觀點,以不斷地超越軟體設計開發的招式與心法。

    如果只有模仿、記憶,而不願意多思考,經驗再多也不可能磨成心中的那把劍呀。

  7. 華山論劍表示:

    我是覺得

    技術差的才會在技術裡說哲理
    沒道理的才會在哲理裡談技術

    與 生魚片 及 jim yeh 共勉

  8. jim yeh表示:

    「誰」技術差不差,是不是沒道理並不重要。重點是「為什麼」我們聽不懂他們的哲理?當然,聽不懂就說他們能力不好,或是沒道理,這也是一種方式啦,只不過這種方式對自己的成長沒有太大的幫助。

    不過還是祝樓上的朋友,good luck。

  9. 生魚片表示:

    拜託華山的中國人不要來這邊吠.
    同人對我來說根本就是神,連他放的屁我都覺得聞起來獲益匪淺.
    難道你的技術有同人強?還是你的哲理有比同人好?
    你還是回去中國論你的賤吧,你管同人技術差還是沒道理?!
    反正我們台灣人聽起來受用就好了,誰管同人真的帶領成功幾個專案?!又或者寫過哪些成功的系統?

發佈留言

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