交大電物61級 Blog

我在電腦應用領域工作了二十五年，主要在設計應用程式，解決科學家和工程師在石油工業界許多領域裡所面臨或發展的問題;這是我的飯碗。我也涉足存貨，客戶，銷售，會計的商業應用程式修改與設計，只因為朋友有難，拔刀相助。所以從天上到地下，工業界和商業界之間各色各樣的問題，我必須用電腦來解決，讓人們來應用。 早期和初級的電腦應用程式經常是量身訂做的。如果你到西裝店去量身訂做西服，你會被狠狠的敲一把，但你總會覺得很划得來。現在的電腦應用程式如果還是量身訂做的，如果不是應景的(用一次就丟了)，就是粗製濫造，要不就是programmer的素質有問題。 早期的電腦應用程式著眼於應用功能，但是慢慢的就發現普遍性、永續性、和發展性變得越來越重要，就是所謂的實用與適用再加上成長已經是每個程式設計所必須考慮的問題。為了考慮普遍/永續/發展這三個特性，電腦程式裡的物件(Object)與功能的模式設計成為很重要的一環。 模式設計主要的依據是從顧客的描述與問題而來，但是大部分的顧客都語焉不詳，他們認為你這個顧問照理應該了解他的需求，我也必須表示出很懂得他的需求，要不然到手的鴨子也會飛走的。根據我做過的大型(超過一年)project的經驗，顧客把他認為你必須知道的部分告訴你，通常這部分只佔了你所應該知道的十分之一；得到了這起碼的十分之一的知識以後，我必須在很短的時間用各色各樣的方法繼續挖掘與補充基本的知識，其中最有效的方法就是持續與顧客做專業的對話。如果我的顧客真是這一行裡的專家，這個專業對話就能很成功的達到我的需求，而且我的專家顧客也會有英雄相見恨晚與惺惺相惜的感覺。如果他是個草包或只是行政管理人員，如何去找到真正的專家就是一大課題。通常這個補強知識的工作就佔了十分之二。我碰過一家公司，他們要我做的工作是他們研發部門想做，但不知從何做起的問題，當然我也不知如何與他們做專業對話，因為他們沒有一個人懂這個東西，所以免談。有一回因為沒有時間再接新的工作，所以我鼓勵我的新顧客提供我細部的要求(specification)，結果他花了大半年的時間，什麼也弄不出來，後來經費被其他部門吃掉了。所以幫助顧客提供比較完全的project specification是一個助人助己的好竅門。 獲得大概的專業知識與相關的挑戰問題以後，如何展開模式設計，將各種不同性質的專業知識和數據焠取出他們的主要定義與相互關係來成就所設計的模式就是我自己所謂的Model Abstraction 抽取模式。在以物件為主的應用程式裡，每一個物件幾乎都必須考慮到所謂物件生命期必備的三要素：產生、改變和消滅。有些物件與物件之間還有衍生的從屬關係。如果再加上上述的普遍/永續/發展這三個特性，有關如何在應用領域裡抽取模式就成為模式設計裡非常有挑戰性的工作。如果抽取設計後的模式是對頭的，再下來的程式設計就非常通暢，要如何的添加或發展都沒有問題；如果抽取設計後的模式不對頭，不但程式寫起來很吃力、怪怪的，交件是要交件，但是交件以後可就寸步難行，比那個量身訂做的好不到哪裡去。 在抽取與設計模式的過程中，不斷的展示設計中的模式來獲得顧客的認同是一個必要的步驟。有人閉門造車了大半天，結果與顧客要的是南轅北轍，不但時間泡湯了，也在信譽上遭受很大的損傷。 你或許會問：我提到十分之三的專業知識準備工作，其他的十分之七用到哪裡去了？根據我的算法，當模式設計完，應用程式也驗收交件時，就是完成了另外十分之二的工作，換句話說，我認為一個project完成時，只不過完成了一半的工作。我把一個研究員的前瞻遠見變成一個實際的應用時，同時也鋪設了一個平台，使他可以站得更高看得更遠。經常在我的顧客升官發財之時，也是我們一起摩拳擦掌，準備下一步驟的發展，也就是完成另外十分之五的工作的大好時機。 十七年前，我為一家石油公司設計應用程式，利用已開發中油井的資料來預測探勘中油井可能發生的情況。根據所有的要求與面談，我設計的模式就是油井對油井資料的計算與轉換。等到他們很滿意的使用了一兩年後，他們發現如果預定的探勘井選得不甚理想，他們想把我的程式擴展用來在地面的一條線上來選一個理想的井點。那時我把這個工作交代給別人做，當時我認為模式必須重新設計為2 Dimensional Model Application,原先的設計是1 Dimensional Model Application, 只是一個special case。我很當心工作人員取巧，只把原先的程式從上面套一層loop充數。果然預料中的事情發生了，而且窒礙難行的情況也發生了。隨著3 Dimensional Seismic Survey 的發展和電腦科技的神速進展，石油公司也要求我把2 Dimensional Model擴張成3D Model。有了前車之鑑，而且對所謂的模式設計也日漸上手，所以在別人看來是難題，我們倒是駕輕就熟。 如果在十七年前設計那個應用程式時，能夠想到顧客所要的是地底下某些點的資料，而不被這個井那個井或這條線那條線所迷惑的話，整個設計過程應該是輕鬆愉快，乾淨俐落，這也是我要談Model Abstraction 抽取模式的主要原因。 在 1D 的 project 裡我的模式很忠實的反應了顧客的需求，但是我沒有仔細的去思考當初探勘井的井點是如何決定的，反正是由別人的應用程式的結果選出來的，如果我們能讓他們知道他們選得不太恰當，我的顧客就成功了，我的任務也完成了。我的顧客建議他的顧客挖井要用多大的孔俓，越大越花錢，但是如果不夠大，恐怕達不到要求就挖不下去了，而且在某些深度的地方可能會爆井，現在一口井經常挖到1~2萬呎，經費在一百萬美金上下，這樣我們就可以了解這種建議的重要性。當我們的 1D program 經常告訴別人：他們選的井點選得很不恰當以後，他們就建議我們替他們選一個好地點，這是我想都想不到的，或者是我的顧客認為我不需要去知道有這種可能性。 在另一個應用 project 的抽取模式的過程中，根據我的邏輯和物理思考，我發現有一個中繼步驟，我的顧客從未提及，但是這一個步驟是一個回饋循環的一個信號修正點。這一個中繼步驟有它的物理意義，我的顧客們有的有了解，有的表示聽都沒聽過(讀書不求甚解)，當我獨排眾議，設計了這麼一個步驟，那個不求甚解的經理要我把它拿掉，最後我只好多花一點時間，再補充他要的樣式，但是也保留我原先的設計。一段時日以後，他們終於了解我為什麼要這樣做，而且其他的同行也紛紛仿效。對的就是對，他們不了解是他們的事，擇善固執是我的原則。 從事了多年的從對話中抽取模式的工作模式，我發現我的腦子已經習慣於一面傾聽訴說，一面從訴說中抽取模式，一面套取更多的資料，來構建這個話題裡隱含的模式。有一次我老婆的妹妹提到她的公司裡會計系統上的問題，很奇怪的是：我居然可以和她一問一答，談了大半天，好像我們就要開始針對這些問題開刀，來替她們的公司設計一個新的系統。在與朋友聊天時，這種抽取模式的習慣也不斷的在進行。老婆不只一次告訴我：人生不要過得這麼複雜，過得這麼累。我也只能怪自己的勞碌命，一輩子只能退而不休。 你知道嗎？我寫這一篇文章的動機，主要是為了林覺民的《與妻訣別書》；我想要去挖掘這封信的真正屬靈模式spiritual model, 就像以前在海峽兩岸，駕機歸來的義士們，根本就不是什麼義士。 *** 老林