我一直都在資訊界工作,除了前兩、三年比較常寫程式外,往後幾年寫程式的機會越來越少,尤其最後這四年,大概都已經望程式興嘆了,正想準備金盆洗手,不再過問程式設計這惱人的差事,沒料到人在IT界還真是身不由己,又被抓下海重操舊業,真是始料未及。

這還不打緊,記得第一份工作,就是因為誤入 COBOL 的勢力範圍,馬上草草敷衍幾個月,就給他落荒而逃。 誰知道現在又給他逮個正著,每天還非想著他不可,真是冤家! 說到 COBOL 真讓我頭皮發麻,用他寫程式,就像叫李敖打字寫文章一樣,打了一個字,整篇文章都已經想完了,就是忘了下一個字要打什麼! 有夠彆扭的。

當初應徵這份工作,雖然知道是一個 COBOL 的專案,但是想我年資也不小,花錢請我不會笨到要我寫程式吧。 呵呵,真是想太多了,這丁點年資算啥,靠邊站去! 五年級中段班這樣的高齡,在前兩份工作都已經是數一數二的人瑞了,但是在這裡,挖靠,是數一數二的幼齒! 而且,不管老少一律捲起袖子,全部下去寫程式,還有什麼架子好擺?

寫就寫唄,既然人家前輩們都能寫,我當然也不能示弱,對不! 只是,又沒想到,也算長了見識,第一次看到 COBOL 這種老古董,可以用來建構物件導向架構的系統,那種驚訝就好像看到一群工人用糯米加磚頭在建構貝律銘所設計的現代幾何建築一樣,真是神奇啊,也真是辛苦啊!

你知道為啥我們都被逼下海寫程式嗎? 就是因為這架構太難懂了,沒人敢接我們發包的程式,真的,到職後的半年裡,外包商更軼不斷,大都來不到一個月,就打退堂鼓。 眼看著我的設計文件都寫好了,還是找不到人,那…就自己造孽自己了吧。

到底有多難? 市面上物件導向架構的系統幾乎已成主流,我看是你沒見過世面吧! 唉,看倌有所不知,有新穎的系統可玩,我當然是見獵心喜囉,只是你要負責餵它吃,那可真是苦差事。

COBOL 這個語言,與資料庫的互動本來就是很弱,以前寫 COBOL 的人大都只有檔案處理的經驗,檔案間沒有關連的機制,所以,他們會將相關的資料盡量放在同一個檔案裡,就算資料重複放,也無所謂。 因此,你會看到客戶的基本資料檔裡,除了有客戶編號、姓名、地址、電話這些常見資料外,為了有些特別的需求,可能連客戶的手機型號、汽車品牌、信用卡銀行…這些附屬的資料都會放在主檔裡,只為了程式撰寫的方便,因為要跨檔抓資料是很費事的。

但是在物件導向的架構就不是如此了,它非常強調資料的主體性,明明手機自己就是一個主體,幹嘛跟人擺在一起? 所以,在我們現在這套新穎的系統裡,每個主檔都很乾淨,只留幾項必要的資料,其它相關資料,都各成一個主體,彼此互有關連檔來描述彼此的關係。 不僅如此,主體與主體間的關係,還需要記錄發生關係的期間,例如;客戶目前用手機是哪一天開始使用的? 去年聖誕節該客戶又是使用哪種手機? 這些都有資料可循。

真是佩服這些做軟體產品的工程師們,鐵定是有技術潔癖,非把每項資料正規化到乾乾淨淨才肯罷休,讓我們這些導入的廠商恨的牙牙癢的。 你想,使用者哪會知道那麼多技術架構的細節,今天他可能隨性就想要在客戶報表上多加一欄手機的資料,而你面有難色的想樣婉拒時,他一定會說:「這有什麼難的,以前舊系統都是這樣啊,我們要什麼馬上就有,很容易啊,我看你在拿翹吧!」 唉,只能硬生生的吞下去囉,一想到要用 COBOL 來做這件事時,可真是難以下嚥啊!

嗯,苦水好像吐太多了,先岔個話題,說些好的。

當初因為主事者沒有想清楚,以為只是導入系統,不需要太多開發人力,以致於所估的人力很精簡,後來才發現導入這套系統所要的人力,竟然比自行開發來的多,於是,就趕快找人,然,COBOL 人才本來就難找,尤其是找又會 COBOL 又可以接受物件導向觀念的人,那更難,造成我們的人力一直很吃緊。

所幸,佔著地緣之便,找了一票台大、台科大的博士、碩士班學生來兼差寫程式。原先,是因為本專案有些 Java/Jsp 程式要寫,而我們這些老人又不會這些玩意,所以,請他們來幫忙。 沒想到,這些學生真的是資質好、悟性高、耐操、又有初生之犢不畏虎的精神,連 COBOL 這怪物他們也不怕,照樣給你寫的好好的。 於是,大家爭先恐後搶著用,現在不用待何時? 等他們畢業了,可就用不起了,不是嗎?

這群年輕學子,人來人往的,我這樣的記性,要喊出他們的名子可難我了,所以,一律管他們叫小朋友:「嘿,小朋友,現在有空嗎? 幫我寫一支程式」

讓人很窩心的是,小朋友們學歷雖然高,但都沒啥架子,要他們加班,也很配合,給他們時程,他也會有壓力,同事們都對他們讚不絕口,想這樣乖巧的小孩還真難找。 有時候,連我都會吃他們的豆腐:

「啊,不好意思,我這個暑假後就不做了,這支程式我無法接。」

「幹嘛? 你錢賺飽了啊? 」 我不爽的回他

「不是啦,要升碩二了,要開始準備論文,不能再混了」

「吼!寫論文? 你也給我差不多一點,這麼早就寫,你是要投期刊啊!」

「如果說要陪女友,我就放過你,寫論文,這那算理由,不行,寫完這支再走,不用急啦,過完年再開始準備都還來得及,還沒聽過碩士畢不了業的。」

看,我真是教壞小孩的惡人,不過,人家可沒像我當年那樣不長進,最後還是乖乖回學校寫論文去

有陣子,我們加班加的天昏地暗,小朋友們也被一起操的死去活來,每天熬到八九點,假日也不放過。 有一天,已經撐到晚上十點,只剩我和一位小朋友,身子都疲了,還是不忘消遣人家:

「小朋友,累不累? 」

「恩,有點,不過還好。」

「唉,不要怪我狠心操你們,其實我是用心良苦啊,早一點讓你知道這行不是人待的,有機會賺賺外快就好,能跑趕快跑啊!」

切,你明明在作弄人嘛! 人家唸資訊都快要畢業了,能跑去哪裡?


說了半天,還沒提到我來到這裡,幹了哪些活。

我們這個小組,負責每天餵資料給新系統。 咦? 系統還有新舊喔? 是啊,這個專案我們只包後端的批次處理作業,前端的線上資料豋錄作業則沿用舊系統。 當初面試的時候,找我來的主要工作就是負責接收舊系統的異動資料,然後餵進新系統裡。 不要小看這件工作,實在有夠繁雜,這就說來給看倌們聽聽:

首先,我必須先觀察舊系統會吃哪些食物? 然後,再去研究每樣食物經過舊系統處理後,會被分解成什麼樣子? 因為,舊系統給我們的食物都是它分解過的,我必須將它們還原回原來完整的食物,這還不夠,還要知道這些食物進食的先後順序。 譬如說,我分析出來知道今天舊系統吃了一個蘋果以及一杯冰咖啡,在把這些食物還原回來後,還得弄清楚它是先吃蘋果還是先喝咖啡?

乍聽起來,真是令人作嘔! 呵呵,不過,我還熱在其中,蠻有趣的。 假如 「CSI 犯罪現場」要拍台北版的話,我鐵定可以去當台灣的何瑞修了,哈哈!

這件工作,從我一到職,花了一個多月開會討論決定處理的方式,我唯一的要求就是:絕不用 COBOL,這要是用 COBOL, 以我三腳貓的功力, 準會寫到天長地久,此案永不結 … 那,不用 COBOL 那要用啥?

想到先前的工作,有稍微涉獵 PL/SQL,對它印象不錯,很容易上手,尤其是目前的工作主要是做資料比對、分析,剛好是PL/SQL的強項。 再加上所搭配的開發工具更是適合給像我這種殘廢人士專用,於是,就決定用PL/SQL來分析資料,完成後再傳回給 COBOL 進行後續的處理。

果然,這個決定救了我,不過短短的三天,我就把程式寫完了。 一寫完,馬上試跑看看,想知道是否真的如我想的那樣,沒錯,哈哈,竟然一跑就 OK,彷彿是貝克漢的黃金左腳發威,踢出完美的香蕉曲球勁射入網,真是痛快至極!

啊,這把寶劍竟然如此鋒利,又好使,揮來毫不費力,劍法隨著劍氣自然地浮現在腦際,完全不用記口訣,劍氣順著手指直逼要害,任對手再刁鑽也難逃! 想那大理段氏的六脈神劍也不過如此吧。 有了這樣的利器,讓我吃了定心丸,決定好好的大開殺戒,既然要我寫程式,那就來吧,就給你們殺出一條血路瞧瞧厲害。

資料還原後,接下來,就是要做檢核,所謂檢核不只是檢查資料本身而已,還要檢查新系統內部是否可以接受這樣的資料。 比如說,舊系統送上一客牛排,首先,要先檢查那食物是否已料理好,各項配料是否齊全,然後,再分析新系統若吃下這份料理,其各項營養成份是否會過量? 所以,得去讀取新系統內現有的最新數據,方可加以分析。這時,我又變身成為一位營養師了。

這項工作不難,只是很繁瑣,又食物的種類本來就很多,而料理的方式更是目不暇給,所以,整個檢核工作的量頗為可觀。 當初是規劃由我負責寫設計文件,程式開發交給外包來做。 哪知外包商一直搞不定,眼看著開發進度落後的缺口不斷加大,所以,我馬上變更設計方式,全部改以 PL/SQL 做資料的檢核,然後再將檢核的結果傳回給 COBOL 主程式由它去發落後續的處理。

各位可能會問,為什麼都要將處理結果傳回給 COBOL? 那是因為新系統只接受 COBOL 程式,所以,還是要把 COBOL 這個空殼子留著,這就叫做:「掛 COBOL 頭,賣 PL/SQL 肉!」

經過三個月的刀光血影,終於也把所有檢核程式都克光了,連原來外包商已經用 COBOL 寫好的部份,我也看不順眼,索性一起翻掉重寫。 拿寶劍來砍這些小咖,真是殺雞用牛刀,這三個月,儘管殺敵無數,但卻是到職以來最清閒的時刻,可見,好的開發工具效率真的差很多。

有如此好用的開發工具,怎麼不介紹給其他同事? 有啊,我哪是那種藏私之人,一有機會,都會不厭其煩的示範這支寶劍削鐵如泥的鋒利,而那些無堅不摧的戰績也是有目共睹的。 可惜,竟然沒人感興趣,從他們的眼神好像認為這不過是雕蟲小技罷了,真不知道他們是怎麼想的。 不過,話說回來,人家的開發進度也漸入佳境,似乎也不差 … 咦?難道是我有眼不識泰山,那把被我嫌到不行的破銅爛鐵,該不會是傳說中神雕大俠那把又沉又重的玄鐵劍? 算了,就算是又怎樣? 我也沒那樣深厚的功力可以使啊,還是繼續用我的寶劍吧。

獨立完成兩件工作後,開始也要去面對本組最難的工作。 這個工作花了本組最多的人力,開發的時間最長。 又是怎樣的工作,如此難? 這樣說吧,那個舊系統就像個飲毛茹血的粗漢,習慣大塊吃肉、大口喝湯,一點也不講究精緻。 而我們的新系統對吃可就講究了,餐具擺設不對,不吃; 沒有餐前酒,不吃; 配料不合口味,不吃;烹調技術不好,不吃 … 不是自備的餐具,不吃; 總之,很龜毛就對了啦。

也就這樣,開始當起廚師,拿寶劍當料理刀,那些粗枝大葉的食材經過我的料理馬上變成精緻的美食,再送給 COBOL 用玄鐵製成的器皿,一口一口的餵進新系統。

整個料理的過程,在寶劍的相助下,難不倒我。 可惜,我的寶劍只能做到此,因為,新系統嚴格要求一定要用自備的餐具進食,而且餐具還要指明用玄鐵鑄成,我的寶劍再怎麼利索,也無法削斷玄鐵,自行鑄造器皿啊! 這也就罷了,君不知選用餐具這學問可大了,每種食物配上不同的烹調方式,所要使用的器皿都不同,讓人眼花撩亂,見習了半天,還是不知所以。 整個開發的過程,都是前面的料理過程很順暢,但到了選用餐具餵食時,卻搞得我手忙腳亂,不斷的請教師傅,一肚子大便! 當然,最後還是把它給了結,挺累人的。

總算,把本組的工作一一都給克完了,那可以封刀休息一陣了吧。 唉,職場上哪有那麼美的事。 忘了跟大家交代,我還有個拖油瓶一直沒時間去理它,現在該是去看看它的時候了。 說它是拖油瓶,因為它完全不是我生的。 在剛到職沒多久,專案經理可能看我年紀較輕,對於時下流行的Web 開發應該比較熟捻,所以,就把這個已經用 java/jsp 開發完成的系統交給我看著,以後負責跟使用者測試。 唉,殊不知我也是 anti-java 的擁護者,java/jsp 是僅次於 COBOL 讓我頭皮也很麻的茶包。 (ㄟ 羅勃特先生,請問一下,你到底會什麼?)

我們的新系統是國外著名的套裝軟體,它的功能繁多,所提供的線上查詢機制也很複雜,一般前端的作業人員很難上手。 所以,我們又另外用 java/jsp 客制化一套比較簡易的查詢系統,就是我那個拖油瓶。

因為它已經開發完畢,且自己手上的工作一直不斷,以致於很少去理會它。 眼看著平行測試即將展開,也該寫寫操作手冊、安排測試計畫,於是,就叫小朋友幫我把它架設起來,開始要測試啦。

才測一項客戶查詢,找個客戶就要等個三十分鐘,就在等待的時候,周遭同事已經抱怨聲四起:「是誰寫的爛程式,把系統都拖掛了!」 驚動專案經理親自下來抓元兇:「羅勃特,就是你的機器,這是那們子 SQL 啊,全都是 Full Table Access,Index 都沒用到,你趕快去調校一下」 聽到元兇是我,趕快跑過去認罪,心裡不甘的咒罵著:「是誰家小朋友寫的,還不趕快給我領回去重寫!」

回到座位,趕緊把那支 java/jsp 程式仔細端詳了一會,唉,也不能怪小朋友,前端的要求是這麼的多角度,後端的資料又是這麼的零碎,能夠將 SQL 正確的組出來就不錯了啦。 看來,我的寶劍又要出鞘了。

在確定 java/jsp 已無改善空間後,我決定用 PL/SQL 來重寫查詢的部份,於是找來一位小朋友,請他將原程式中所有的 SQL 指令都刪去,直接改成呼叫我寫的 Store Procedure。

「你把所有的查詢參數傳給這支Store Procedure,等它處理完後,會將結果寫到這個暫存檔裡,你再把結果抓出來顯示就可。我們就先試改一支看看,若效果不錯,再全部翻掉。」

很快的交代小朋友如何改,兩個人就開始分工去進行,不到半小時,就寫好一支查詢,迫不及待的試跑一下:「挖靠! 兩秒鐘,只要兩秒鐘,真是太神奇了!」 真的還假的? 不敢相信,再跑一次,還是兩秒! 心裡興奮的要死,趕快去找小朋友,讓他見識什麼叫做寶刀未老!

「吼! 你都是用 Cash 在跑,當然會這麼快啊,真是有夠瞎!」

啊,真是有夠白目,因為撰寫的時候,一直都是用同樣的查詢條件在測,所以 … 竟然被小朋友抓包,有夠丟臉,就像一個洩了氣的皮球呆坐下來。

「不過,也只花三十秒,比起原先三十分鐘,已經改善很多了啦」小朋友看我似乎經不起打擊,連忙安慰我。

「小朋友,給你一個機會教育,對於性子急的使用者,三十秒跟三十分鐘是沒有差別的!」

一個劍客,若無法在須臾之間,讓對手見血封喉,一劍斃命,還要三十秒,這跟屠夫有啥差別?

今天就測到這,明天繼續,說完,蓋上電腦,走人。



在無味的工作裡,偶爾來點狂想,是感性存在的價值

arrow
arrow
    全站熱搜

    yangtsuyu 發表在 痞客邦 留言(6) 人氣()