我跟他的觀點截然不同

我跟他的觀點截然不同
從高鐵售票系統談大型公共建設軟體開發專案 (我一直在不斷的強調,真正高負載的系統是不會使用RDBMS的,而高鐵的問題是Critical Section的問題,跟系統本身使不使用RDB是完全無關的)

1.不要猜問題所在

一個大的系統出問題時;常常很難有一致的答案,有時候表面上看起來是那樣,改完後也確實改善問題,但事實上問題並不出在這邊,這樣的事情常常發生週而復始,因此;當系統出問題時,需要猜測問題的所在,而且應該假設有錯誤的地方不在表面上看到的那樣,最後需要一針見血的猜測(排除絕對不可能的部份,試圖讓問題縮小,然後找到最可能的原因),絕大部分的問題一開始我們都不能知道答案,尤其是我們往往假設,我們所使用的工具是正確的

2.解決問題的心態

這個觀點也是錯誤的,事實上開發人員並不是在大型專案中試煉自己的技能,不斷的調適、熟練的過程...,這些應該是平時應該要做的工作,因此;我們希望RD至少有1/3 的時間在做研究 2/3 的時間來作發展,事實上我們還希望把比例顛倒過來,當一個開發人員,有了純熟的技能,自然能夠避免犯下不可彌補的錯誤,甚至在開發的一開始就能避免很多不必要的浪費,而且能夠開發出強壯且靈活有深度的架構,因為他平常已經練習好,而且它有很多時間練習,而不是把作專案或是產品當成是練兵
========================================================
上回遇到NOVELL 的外聘開發人員,我把我自認為RD 為軟體公司核心的理論跟他交換意見,結果他卻要自斷經脈,他說RD通常不懂市場...,寫出來的東西不知道要賣給誰,我聽完當場昏倒,我想請教的是軟體公司的核心如果不在技術,而創造技術的不是RD ,那麼這家公司確定是軟體公司嗎? 一個出色的RD 必然理解市場脈動,至少他會有一個值得參考的產品技術觀點,只有三流的軟體開發人員才會自甘墮落淪為高級打字員心裡想著何時要轉為PM...,真正出色的工程師不僅解決問題,他還能引領整個公司的發展方向,我們要看5年後的技術將往哪發展,我們要創造公司的技術研發的沿革歷史,而不僅是今年公司要賺多少錢

由高鐵訂票系統現象看技術

事實上有經驗的工程師,即使沒有寫過票務系統,一聽到座位會重複劃位
應該可以馬上就知道問題出在哪,舉個簡單的例子: 一個pool裡有20個
不重複的號碼,現在要從pool裡拿出不重複的號碼排在桌子上,跟高鐵的
售票系統就很類似,(這是Critical Section的問題),一個junior的
工程師,很可能使用select 的方式由table裡拿出未註記的座位號碼,
訂位後把座位做標記,然而;這樣完全沒有transaction的觀念,由訂位
前取號到訂位後註記,多工(多人連線)系統可能同時處理2以上的程序,
於是可能發生同時取得相同號碼的問題,這是很嚴重的系統規劃問題,取
號應該是同時只能容許一個程序進入(lock),訂位前到訂位後為同一個
transaction,應該要有成功與倒回的做法,然而;這些機制卻是很少人
會去注意,難怪;高鐵的系統會出現這麼可笑的問題,我想或許高鐵的開
發人員連如何lock 都不知道,這就是只會使用db 開發程式的RD會發生
的事,另一個有趣的問題發生在,為何系統上線前的測試沒發現這麼嚴重
的問題?我想做上線前系統測試的工程師絕對也是一個初級生,單工的測
試,怎麼可能測試出多人連線的狀況,或許這些工程師還在想,不可能阿!
我之前都有測試過,沒問題怎麼會這樣?呵呵..這句話應該是programmer
常說的話之一;這問題跟使用 db使用自動編號(or oracle內的serial
使用) 或是直接SELECT MAX(number)+1 ... 寫入db 所會發生的問題
很類似,只要是稍微有經驗的工程師就知道,確實的原因絕對與高鐵發佈的
消息完全無關,系統的規劃 撰寫 全是一群非常資淺的工程師所組成,這才
是主因,我相信這個系統與台灣彩券系統一樣,還有很多潛在的問題沒被挖
掘出來,這個基礎的設計問題事前都沒注意,何況是更深層的系統問題,而
這些目前看不到的問題才是真正可怕的地方