喲哪桑提出為了軟體維護的二種設計策略,在設計的彈性策略方面,提到了我的〈專案成本估算之軟體價格的迷思〉某種程度上也說明了為何開發者難以達到彈性這個理想。既然學長提到了,我也好藉這個機會表達我在這方面的看法與經驗。
《易經.繫辭傳》有言:「天下事一致而百慮,殊途而同歸」。在不同產業中,設計所呈現出的面貎也許不盡相同,但是其策略本質卻是不會輕易改變的,亦即為未來可能發生的變動提供適應變化的能力。然而,開發者想要讓軟體具備足夠的彈性,以符合未來可能會面臨的需求改變,抽象化思考與設計能力會是關鍵因素,加上專案成本估算之軟體價格的迷思所形成的動態模型,當我們愈想要加入有彈性在我們的軟體設計上時,就更難以面對市場的競爭壓力,於是只好放棄設計彈性的理想。記得我和吳宗成教授曾經討論過國內軟體設計的議題,依照吳教授的觀察,他告訴我:"台灣的軟體開發者大部分都在做 concrete design 而非 concept design,有用的設計是 concept design 而非 concrete design"。由此可知,在台灣軟體開發環境不重視設計的情勢下,大部分的人多抱持著:今天先把功能寫出來,明天再求最佳化往往是軟體專案以時間換取空間的常見做法;我並不反對這種看法,但設計者必須培養持續改善的專注力,好的設計其實源自於紀律。
設計真的沒辦法堅持彈性的理想嗎?如果我們願意換一種思維方式,是不是就可以堅持理想,試圖打破軟體價格的迷思。於是,我們換一種做法,不以降低軟體開發成本為目標,而是藉由邊際效益的提昇來展現設計的附加價值,強調高品質的軟體設計及好的軟體來自於軟體工程的想法,不再自廢武功落入削價競爭瘀惡性循環中。換句話說,當我們體認到軟體維護的重要性時,就必須為未來可能的改變而設計,以保有系統修改及維護的彈性。那要如何做呢?我們可以學習別人良好的設計範例,先從臨摩就座開始,慢慢提昇我們的設計能力。於是,我們向 design patterns 取經,學習如何為不確定來設計、體會務虛的設計藝術。
然而,design pattern 的學習看似簡單,但學了之後,要真正用在軟體開發上,卻又不是那麼一回事。看得懂是一回事,要實際去用卻是另外一回事:為什麼那些大師可以「化腐朽為神奇」,運用 design pattern 使設計變得更有彈性,而我們常把能用的 pattern 都用上了,不但沒讓設計變簡單,反而讓設計變得相當繁複,要了解它都很困難了,更不用說實作與維護了。〈由招熟漸悟懂勁〉告訴我們設計招式與心法搭配的其中奧妙所在:
設計技巧如何,因人而異,面對相同問題,每個人可能會有不一樣的設計手法,程式寫得愈多,對設計愈有不同的體會,如果你對程式如何解決問題沒有深切的體認,很難設計出彈性及功能兼具的系統。所以以個人的心得來說,業務流程、演算邏輯及程式語言的技巧是招式的運用,而內化的領域知識、OOAD 的分析設計原則、封裝、抽象化乃至於 Pattern 的運用則是心法的展現。這兩者互相反覆搭配、增長。
運用 design pattern 雖然是增加設計彈性的利器,但為了維護這些設計彈性,卻必須付出開發成本,當我們的設計充斥了「沒有用的彈性」時,就會浪費許多無謂的時間與資源,而不會再有足夠時間回應軟體需求的變化,及足夠的空間來容納真正需要的功能。以經濟學的角度而言,設計者須重視設計的機會成本,要為現實需求而設計,避免想太多而造成軟體設計的過度工程化的後遺症,而在設計上充斥著沒有必要的複雜度。以物件導向設計原則而言,抽象性愈高的套件,穩定度就要愈低,否則它就會沒有什麼用處,穩定度愈高的元件,抽象性就要愈低,否則它就會很難被重複使用。總之,要設計彈性與功能兼具的系統,其實最關鍵的是務實與務虛兩種設計策略能夠相互達到均衡,以達成設計與實作觀點的兩分之形,如下棋般,讓不同觀點皆能發展出最佳的著手。
閱讀全文 →