同人的生活派對

程式碼的重覆性使程式不容易維護、以及增加系統出錯的機率，同時使得程式的再用性難以提昇。因此降低程式碼的重覆性對程式碼的品質與彈性有很大的助益。然而，在資料存取與與物件型別的無法分離的情況下，卻會使得開發者難以對治程式碼的重覆性；相同處理資料的邏輯，受限於處理資料的不同型態，使得開發者必須依據資料型態不同，而改寫同一段程式碼，使得程式碼很難共用。

就像一個比較常見的例子是資料永續存取的實作，常會因為存取資料型態的不同，而影響到資料存取的界面，因此對每一個需要持久化的商業領域物件，都必須重覆地實作它們的 CRUD 存取功能。

雖然透過永續層的概念，我們可以將這種重覆性隔離開來，加上有些 ORM 永續框架的協助，開發資料存取物件的負擔並不太大。然而即使如此，我們有沒有可能避免重覆開發資料存取的元件，不用針對每一種物件型別都要寫一支相對的資料存取物件呢？要達到這樣的目的，我們必須分離資料存取的處理程序與物件型別，但要如何才能做到呢？ Read the rest of this entry »

在〈開發者的 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 字眼才知道是訊息格式的問題，那改天換了另一種交易訊息的實作方式，我想大概他腦筋又要轉不過來了吧。

以上網友的三種批評，表面上看起來好像是不同的問題，但其背後都存在同樣的本質，那就是從交易訊息的問題中可見一斑，他們無法以抽象性思考來看待軟體開發的問題。但為什麼開發者需要抽象化思考呢？ Read the rest of this entry »

昨天同人在〈又見少了概括性論點〉提到〈必須面對的真相─五大程式設計迷思〉在文章結構上的問題。其實那篇文章除了結構問題之外，同人也在該篇文章內容中，發現了一些值得探討的問題，因此想在這篇文章發表我的看法。

以該篇文章內容而言，同人認為值得探討的有兩個地方，一個是程式語言一直再改變的迷思、另一個則是作者建議讀者，儘量避免用遞迴的方式來寫作程式。第一個問題只是沒有交待清楚作者想要表達的概念，而第二個問題就是嚴重的偏見了，值得讓人進行思辨以建立正確的觀念。 Read the rest of this entry »

最近同人看到有一則噗浪提到「一個穩定的程式並非必然，而是偶然」在此噗浪的回應中，發送這則噗浪的噗友表達他對程式穩定性的看法。

先問自己一個問題，一個程式有幾個 Bugs？如果是不可數，那～～它的穩定是相對非絕對，所以穩定不是絕對的，也不是必然的。

同人覺得這位噗友的觀點很有趣，於是加入這則噗浪的討論。我問如果最開始的程式都是穩定的，那麼是什麼原因讓後來的程式變得不穩定？對這個問題，一些噗友提出了他們的看法，其中有一位噗友回應「是我的機器弄好的程式，跑到別人機器就不穩定了」，發送此則噗浪的噗友認為還蠻接近實際的情形。

他提到 Bugs 在自己的機器沒產生，在別人那邊可能會產生，問題可能是因為自己的機器有 Bugs，而不是別人的機器，他說假設機器不會出問題是會有副作用的。

那麼為什麼不在應用系統要運作的目標環境下直接開發程式呢？因為，嚴格來說，開發者不可能有完全一致的環境，因此開發者只能假設環境是不會改變。但實際上，在不同的機器上、甚至在相同的機器上，不同的時間可能也會出現難以預料到的變化，結果使得程式變得不穩定。

這位噗友認為，當我們愈信任一個系統，其實可能是一個災難，因此程式的穩定非絕對而是偶然，它是由一連串的偶然所累積而成的。同人發現這個觀點讓人很難反駁，在我過去程式開發的經驗中，並不乏遇到原來運作正常的程式，在不同時空環境出現問題的現象。正如同這位噗友提到的，作業系統與程式語言它們本身也都是程式，很難確保它們不會出問題。

相信很多人都曾遇到過，程式發生失常通常只因為一個令人難以捉摸的小錯誤，因此似乎真的可以說「穩定的程式是偶然的」。不過，如果穩定的程式真的是偶然的，程式的穩定就只能依賴運氣而不是人為努力，事情真的是這樣嗎？其實這位噗友太過強調環境變化的隨機性，卻忽略了適應環境變化，程式開發必然會經歷複雜演化的過程。穩定的程式是演化而來的，雖然演化的過程是偶然、但其最後結果卻是必然。換句話說，穩定的程式是偶然下的必然。 Read the rest of this entry »

《黔之驢》的寓言故事告訴我們藏拙的智慧。如同故事中老虎先前不知驢子的虛有其表，以為牠的龐然大物而對產生敬畏之心。但當黔驢技窮的底細被老虎發現後，可憐的驢子便喪生於虎口之下，這都是因為那頭驢子不懂藏拙的智慧。

從事軟體開發的工作，同人常觀察到一些開發者不懂藏拙的智慧，意欲表現自己很有能力，但卻總是被人看到他們虛有其表的黔驢之技。通常這種人不懂得用虛心受教來充實能力，而只會把問題的責任推到他人身上。

我們當然很希望這樣的人，不要出現在工作經驗當中。但很不幸地，世事總是難以如我們的預期，如果不幸在工作碰到這樣的人，我們應該如何自處呢？ Read the rest of this entry »

最近寫了很多的占星文章，不知道有沒有人不習慣呀？為了擔心有些讀者無法適應，同人在此寫了一篇有關軟體開發的文章以中和主題，並用來分享我對彈性分類策略的設計心得。

許多的資料查詢，常會根據某些不同的分群觀點來將資料作分類。例如交易資料中的「產品分類」或是「單據種類」，使用者經常會希望將這些欄位當作查詢條件，讓他們可以找出相同產品分類或是單據分類的資料。

然而，實際上的查詢作業需求可能會比較複雜，也就是使用者可能會需要在一次資料查詢的結果，希望把不同資料分類，但彼此的分類之間卻同屬於相同分類群組的資料顯示在一起。我們可以新增資料分類群組的欄位，並依據資料分類來設定其分類群組的內容。這種作法在資料查詢方面的實作上非常簡便，但缺點則是要在資料的維護上額外花費一些成本。

因為這樣的設計會造成資料欄位的遞移相依，違反資料正規化的原則。當資料分類內容修改時，分類群組的內容也要跟著修正；而實際上很可能會因為程式的瑕疵或系統出現異常現象而造成資料不完整或缺乏一致性的風險。

而且，很多依據分類群組集中查詢的需求往往是在專案後期才提出來，如果開發者並不願意因此改動資料庫結構，要如何在不增加群組欄位的情況下，實作出依據分類群組集中查詢的功能呢？

答案當然是將分類群組欄位化成對應的查詢語法或群組欄位的顯示內容，這樣會讓查詢資料的實作程式變得複雜些。因為程式實作者除了必須知道資料的來源之外，尚須瞭解群組欄位與資料分類之間如何轉換。而當相同的查詢需求散布在系統各個程式之間時，就會增加程式開發的複雜度與出錯機率。尤其使用者可能會視作業方式來增加分類群組的需求，開發者應該如何運用設計的彈性，以降低程式開發沒有必要的複雜度呢？

同人在此提出一種設計手法，運用彈性分類群組策略的設計來解決以上的問題 Read the rest of this entry »

上次提到用服務層的概念整合業務流程與功能性交易，並指出因應交易流程整合的非同步呼叫考量的兩種技術實作方式，也就是 database sharing 與 message queue 的不同做法。兩種做法會殊途同歸，最後會依據處理狀態，呼叫後端的服務進行後續系統作業。

既然兩種做法會殊途同歸，那麼在設計上，可不可以設計出同時適用不同實作方法的非同步機制呢？依據這樣的設計思路，我們會希望把會變動的部分用界面封裝起來，如下圖所示。

在上圖的設計中，我們定義了一個 ServiceEvent，用以記錄交易識別碼、交易階段代碼及流程代碼等資訊，其中流程代碼的目的可提供系統進行更精細的控制，而交易識別碼及交易階段代碼則是用以取得交易目前處理狀態以讓系統繼續處理交易的後續動作。

ServiceEvent 由 EventAdvice 產生，並由 EventListener 讀取，而傳送及接收 ServiceEvent 的任務則交由實作 EventSender 及 EventReader 的類別來處理，如此便可達到不會因為不同的實作方式而更動到設計。 Read the rest of this entry »

在 OO 社群中，由人稱 GoF 所著的《design Patterns: Elements of Reusable Object-Oriented Software》^[1]被認為是物件導向軟體設計的重要典範，但最近在 InfoQ中文站，有一篇文章的主題是 〈InfoQ: “四人帮”的设计模式经得起时间的考验么？〉，提到這本書最近被人質疑已經與時代的發展脫節，書中解決問題的方式已經可以由新的語言來做更好的處理，用書中的設計樣式^[2]來解決設計問題還會增加不必要的複雜度。

這篇文章提到對設計樣式的反面意見主要包括了設計樣式是一種複雜性的表現形式、對設計樣式的樣板式代碼（boilerplate code）的需要，代表在設計思路上的問題，也就是開發者所使用的語言基礎結構出現問題的信號、以及設計樣式阻礙了《A Pattern Language – Towns, Buildings, Construction》這本建築架構思想的傳播，本書是被公認是激發了資訊科學領域內的設計樣式運動。
Read the rest of this entry »

1. 中文版為由葉秉哲譯（2001），《物件導向設計模式》，美商普林帝斯霍爾國際出版。[↩]
2. 有關 design pattern 一詞，中文有兩種翻譯方式，設計模式與設計樣式，同人習慣用「設計樣式」來稱呼之。[↩]

前文提到在查詢永續物件的後端實作上，在處理 where 條件式的部分，對於物件查詢的樹狀結構條件表示式而言，可以運用 GOF 的 interpreter pattern 的觀念，藉由尋訪語法樹的過程中來予以解析同時加以處理。

但在實作的考量上，相同的條件表示式在解析處理上卻必須隨著採用的永續框架而有所變化。因此，解析處理的實作並不能放在 QueryExpression 中，而是必須將解析處理的概念封裝為尋訪器的界面，讓 QueryExpression 可接受不同尋訪器，以容納可針對採用不同永續框架而有不同解析處理的功能。

此種做法其實就是利用 GOF 的 visitor pattern 來增加系統設計的彈性，但限於篇幅，前文並未交待要如何做，本文就是要接續這個問題來做後續探討。首先，我們定義用來解析處理樹狀結構之條件表示式的尋訪器界面，即 QueryExpressionVistior，它知道如何尋訪條件表示式中的各種資料型態。然後讓 QueryExpression 可以接受不同的尋訪器來解析處理條件表示式：
Read the rest of this entry »