輕鬆談軟工

『如果我問我的顧客想要什麼，他們會回答我一匹跑的更快的馬』- 亨利 福特 最近上了一本新書『 Inside Steve's Brain 』，說的是蘋果賈柏斯對經營、設計的一些理念。我想大家對賈柏斯轟轟烈烈的事蹟一定很熟悉（特別是蘋果迷），在此不做贅述。我個人雖不是蘋果迷，但也深深的佩服他對設計的執著與相關產品的簡約。我一直覺得台灣需要的不是系統實作人才，應是軟體設計人才。設計是什麼？我所說的並不是什麼結構性設計、物件導向設計、架構設計等技術的東西。 而是態度。一種對設計的態度。 什麼是設計的態度？答案也許在這本書中。推薦各位看看。 一般而言，軟體工程裡都教我們系統分析時要做需求訪談，聽顧客的話。但在某個領域中，特別是創新的領域中，傾聽自己內心的渴望（對產品的渴望）是更重要的：我們如何能做出讓人能夠感動的產品？Steve 相當欣賞亨利 福特的一句話：『如果我問我的顧客想要什麼，他們會回答我一匹跑的更快的馬』。 在顧客的框框下，你所開發出來的產品是不會感動人的 ，所以 Steve 在開發產品的時候是不做市調的，這相當有自信且冒險。但對 Steve 而言是行得通的，畢竟能讓一個工作團隊花『六』個月的時間調整一個 scrollbar 的人並不多。

看到「好人難為」一文，主角是一位專班學生，看來他似乎很委曲，因此我在意見箱內提議，他可以好好研究一下軟體設計的第一原則：Open-Closed Principle (OCP)，或許可以解決他的困擾，這件事涉及到軟體工程的教育與訓練的問題，也就是說，學以致用的問題，因此有必要寫一篇短文以OCP為例，來談談軟體設計原則的運用，這些原則並非軟體發展的食譜(cookbook)，而是發展者必須放在心裡的「指引」(guideline)，這種指引必須落實成為diciplines，其他如設計樣式(design patterns)也具有指引特性，因此才能廣泛運用，也就是說，可以重覆使用(reuse)，學習時最好蒐集一些範例，可能有助於這些設計原則或樣式的運用，有如念法律的人必須研究一些判例一樣，學習軟體發展方法時也不例外。 OCP是物件導向方法的核心，1988年由Bertrand Meyer在他的著作" Object-Oriented Software Construction "一書提出，它是說：「軟體實體必須能夠延伸但不能修改」(Software entities should be open for extension but closed for modification)，換言之，必要時可以延伸軟體實體的功能但不必修改它，該軟體實體可以是類別、模組、功能、程式、或組件，完全看你用在何處。Meyer的原意是說，類別實作(或程式)除了須要除錯外，如要改變功能或增加新功能時不得改變父類別(superclass)，而由子類別(subclass)來達成，子類別可以利用繼承(inheritance)機制重用父類別的屬性或作業元，但可改變或增減其功能，因此繼承不旦可以重用父類別的實作，同時可以延伸原功能，該子類別的介面可以異於父類別的介面，這是一般具有物件導向的人所熟悉的繼承機制。 到1990年代OCP被重新定義為，新介面可以繼承自「抽象類別」，但非繼承實作部分，原介面不得修改，也就是說，你設計的組件或模組不能改變，當需求改變時，你可以增加新程式以延伸該模組的功能，但不能改變你也許認為十分完美而能作業的原程式，請看下圖(R.C. Martin)， 左邊圖形表示，如果Client想使用另一個Server時，Client必須改變，因為兩者皆是concrete，這樣就不

對開發軟體系統的人而言，最害怕的並不是寫程式，而是千奇百怪的需求。一個朋友告訴我他曾經做過某個學校的校務系統，在加退選的前一天： 『第十五個選課的人不可以退選』學校突然向他們要求這個需求。 經過了解才知道一門課至少必須有十五位選課才可以開課，否則就會倒班，所以校方就提出這個需求。但是用這種方式來預防倒班也有點奇怪。 有趣的事發生了。甲生是第十五個選到課的人（當然他自己不知道他是第十五位），而第十六位選到課的同學正好是他朋友，甲生眼睜睜的看到他同學可以退選，自己卻不能退選。接著又有其他人加選後退選也可以，但他剛好又是第十五位，他還是不能退選，你說氣不氣人？ 於是這個問題學生提出來，最後只好把把這個限制拿掉。有時候一個系統的功能看起來沒有幾項，卻是在修修改改之間浪費了很多的時間，如果能夠事先想清楚，是不是可以省很多的時間？如果一個有經驗的系統分析師能夠在顧客提出奇怪的需求時就能跟他們分析這些需求後續可能造成的影響，那就有很大的幫助。

我自己以前很喜歡寫程式，現在不年輕了就較懶惰，所以大家猜的出來這故事發生在很久很久以前... 一顆1MB的RAM要一千塊美金，而且要排隊一個月才買得到的時代 。 我當初為了一家forwarder/broker（海陸運）公司寫一些應用程式。幫他們架網路，再完成了會計系統、出入口系統等業務的東西，終於要幫Sales的人們開發他們的系統。花了一些時間，把基本需求完成，然後很雞婆的幫他們作了一個小工具。結果，那個小工具成為Sales的人們最喜歡用的功能。 為什麼說雞婆呢？因為這沒有在他們本來的需求裡，而是在某幾次吃飯或咖啡場合聊他們做事的方法，我自己去作一些prototype開發出來的。其實那個功能需要跨幾個資料庫撈一些資料再整合，只是我們當初所使用的資料庫系統會鎖住資料庫，沒辦法邊看邊編輯資料。其實是為了安全的考量，資料庫鎖住是很合理的事。可是為了這限制，我一直沒有辦法完成我想要的功能。最後，在某一次的嘗試中，動態跑到作業系統裡把lock挪掉，做完工作，再把lock搬回，竟然就完成了所期待的工作。雖然有些危險，但是我非常有把握在這些功能的使用範圍內，應該是不會發生任何問題。 事實上，這工具他們之後用了很久，而且沒有發生任何意外。直到有一天我接到越洋電話... 時間已過幾年，我也搬來台灣。原來他們要upgrade系統，再重建構系統，所以希望我說明當初到底用了什麼撇步完成那功能。 坦白說，我連什麼功能都忘了，哪裡記得什麼妙法？ 不知道各位有類似的經驗嗎？很多時候拼命coding，不是trial-and-error，就是靠著一些靈感完成工作。然後，沒記下來，過幾天就忘光光了。 明明知道要加註解，可是怎麼可以停下這麼順的『手感』，就繼續code下去了。更不用講到文件了...