或許可以說,我身處個人的小危機中。當你慢慢可以看出事物背後的本質、理解來龍去脈,卻不喜歡你看見的東西又無力修改,就會掉入這種危機。
先從售票系統還有彩卷談起吧。我是略略參與過售票系統開發的。那是剛從公司辭職出來,接的第一個專案形式的工作,以約聘形式臨時加入一個月。大概是因為開發已到後期,規格突然有變,人力不足,所以向外找些傭兵。合約的保密規定相當嚴格,我只能說,就當時看到的程式碼,目前系統會有這些問題,並不令人意外。只是在那時點以及槍手身份的職權,我對這種情況也無能為力。
彩卷問題也大同小異。軟體設計並不容易,從前期以及執行中架構的決定,到後期測試方法等等,無一不是學問。而這些系統現在出的狀況,並不是你面對了困難問題,百密一疏所造成的。他們基本的程度,就好像你練短跑卻不懂怎麼起跑、打籃球不懂運球、或者是玩攝影不懂光圈一樣。這代表在整個軟體開發流程中,重要的關鍵動作,從頭到尾都無人做出。這表示有此專業的人並不存在、或是沒有掌權、或是雖有權卻故意省略不做。
這代表:事情大條,並不只是個 bug 這麼簡單而已。整個制度都出問題。就如同你在菜中挑出一隻菜蟲,代表有點小疏忽;但如果一隻大蟑螂自始自終都趴在盤子正中央,而這道菜卻仍然送到顧客的桌上,這時候你就知道,問題不只是疏忽這麼簡單。
更耐人尋味的是,在問題浮現後,神通電腦處理的方式。他們將錯誤導向規格問題,表示是由於高鐵要求的規格「是以航空業標準來規劃」才造成系統現在的狀況。我們必須弄清這動作背後的含意,如果規格有問題,責任就是在高鐵而不是神通,而高鐵如果要修改規格,由於跟專案一開始不同,勢必被科以天價。這也是高鐵後來為甚麼一直放話,表示包商必須無償負責修改,以及系統純粹是設計不佳,與航空業規格無關的原因。這其實都是公司之間的角力。
今天的中國時報「高鐵票務軟體沒寫好 釀成不可思議的亂」大概點出了這個問題,然而其中「科技公司高層」表示的「專業立場」,卻又犯了根本的錯誤:
這位參與過運輸業票務系統的專家分析,台灣高鐵公司之前會發生重覆訂票的事件,很可能是時間差沒控制好。例如,如果甲從十二點零一分零一秒開始自動售票機買票程序,在零一分零五秒才完成程序,而在這空檔期間已有別人搶先一步訂了這個的座位,結果電腦還是回覆甲說座位沒問題,就會造成重覆訂位。
「我們設計軟體,時間差是以毫秒計算。」他表示,多人在同一個毫秒訂下完全一樣座位的機率很低,軟體如此設計就可以避免這種問題。
以上這段話從一開始的正確講到純粹狗屁。就一個高流量系統來講,就算時間差弄到毫秒也一樣不保險,「機率很低」就是不夠好、就是無法避免。目前 CPU 隨便都 1GHz 以上,一毫秒的時間就跑一千個指令了,算到毫秒又怎樣?由時間來處理根本就錯了,這只是最基本最基本的 read/write lock 問題,所有教科書都有。最後還來個老王賣瓜說自己設計軟體都以毫秒計算,這臉豈不丟得更大?我毋寧相信此高層是受害於作者的錯誤理解與引述,而不是他自己真的這麼想。
種種事情不禁讓人害怕,台灣的專業人士都死去哪了?這麼重要的公用系統不能謹慎開發、天天看到記者的不當發問與錯誤報導、資訊軟體業嘴皮子重於實質,打好人脈才是重要... 尊重專業好像成了口號,專業不過是對意識的服務。這就引伸到一九八四這本書,還有杜正勝的事情。
不喜歡文章落落長,下次再說了。
看来有很多问题,在两岸的情况是一样的。
回覆刪除你還是早點習慣這個無賴行業吧~ :P
回覆刪除這就是人生吧。反正扯一些奇怪的單位好像就很專業,read/write lock?那是什麼?能吃嗎?
回覆刪除