為何SA很難落實簡單設計？

2則回應

分享

    

前文已提到系統分析師在面對軟體開發難處時，究竟該如何應對：設法做到簡單設計；接下來要分享的是，為何簡單設計這麼的知易行難。

「本質」的誘惑

雖然說系統分析師需要紀律以思考問題、以及實踐解決方案，但實際上要做到真的很不容易。筆者從實務的觀察中發現，很多系統分析師在設計過程中，都很容易受到本質的誘惑而更加深了結構與非結構的隔閡。

所謂的本質是指不管環境如何改變，但仍然會有不受環境變化衝擊的觀念或方法。筆者並非否定設計本質的價值，只是覺得「本質」這個詞很容易讓人們陷入迷惘。設計能力愈強、或是經驗愈豐害的人，愈容易受到本質的誘惑而迷失方向；一旦你愈堅持你所相信的設計本質，你就會愈容易忽視思考問題的存在。

在軟體設計社群裡，「本質」是個很容易被濫用的名詞，筆者認為系統分析師應該要謹慎地看待這個名詞，以免受到它的誤導而弄錯問題。筆者曾經在 plurk 看到生魚片提到，從 OO 的本質下手的心得，指出搭配重構與設計樣式再行體會，讓他更認識 OO 是什麼。我當時則提醒他當心設計本質很容易讓人弄錯真正存在的問題。

對於我回應生魚片的看法，cloudy 提出他的觀點。他認為設計本質是不會變的，只是在不同問題領域中，設計概念的資料與行為會有所增減。筆者倒是認為問題的存在會決定事物本質的不同，例如訂貨系統中的車子、與租車系統中的車子，在設計上是屬於完全不相同的概念。前者是達成交易的商品，而後者則是用來提供服務以收取租金的生財器具，真正販售的商品是租車服務而非車子本身。

如果同樣以「交易為中心」的設計模型，都存在這種本質的差異，那麼對於其它無法用交易解決的問題領域，更是難以讓系統分析師找到不會因為環境改變而受到影響的設計本質。因為，當存在的問題不同之時，對相同的事物會產生完全不同的意義。換句話說，設計本質並非固定不變的，而是因應系統所要解決的問題而改變。

其實，筆者也很難避免受到本質的誘惑，以自己過去開發過的銀行影像系統為例，一開始按照自己設計的經驗來建立設計模型，很自然地會將資料進行正規化的處理，對影像文件擷取交易的設計觀點。

但問題是這個系統與以往的專案最大的不同是，它並不需要處理交易的部分，而是由工作流程系統處理交易完成後，再通知影像系統以進行影像資料的存取。隨著使用者需求的變化，調整功能時卻發現交易的設計反而讓問題變得很複雜。這時才發現，以交易為主的設計本質並不適用於這個系統，而是重點在於如何讓使用者建立查詢檢索條件，方便讓他們找到需要的資料。

交易在此系統並不代表交易事件實際的發生（有沒有發生對此系統並不重要），而只是代表影像查詢或檢索的某一種條件限制而已。由此可知，想要找到對系統真正有用的設計觀點，並非針對事物的真實情況（本質）來建模，而是因應事物在問題領域中所表現的價值或意義（存在）來建模。

筆者認為，系統分析師應抱持開放的心胸，體認到軟體設計本質的未定論；存在並非由固定不變的本質來所彰顯，而是藉由創造本質的過程來體驗問題的存在，設計其實是「本來無一物，何須染塵埃」。(未完，請按下一頁繼續)