其實,
這種系統,
也不是什麼創新的新系統,
我不覺得 瓶頸是在技術問題 或者是業界軟體主管需要我們指導.
有些建議,其構想的背後所需的先天條件,
可能已經跟某些 業界環境的限制式有些脫節,
似乎,在一些產業中,不少公司之間的人事,是有同盟或合作在的,
純 技術人員,尤其是程式設計師等,很多專業工作其量是階段性的,就會滿像打工仔的,
也許這邊某種技術性質的工作,已經似乎完成時,短時間沒有新需求,
就可能被 "調" 到另一家公司, 原工作由其他人接手應付.
而也可能直接從別公司 "調" 人來支援所欠缺的某技術領域,解決相關問題.
這樣好處是,
省下人事成本,(尤其是當公司虧損,人事成本又高,不失為一方法)
省下重複摸索/培訓新技術的時間與成本,能立即有極高的生產力,..
(可能還有一些額外考量,或限制,...比方有些職務人員已經被拿來做公關用的)
所以人力資源先天上會有點特殊.
(至於這主情況,常見嗎? 比例多少,也許這個就要看公司,產業,..)
但是,這種模式,也可能有些缺點就是了.
比方像這種大一點的系統,可能過程實經手的人過多,
很多技術人員都沒有從頭到尾參與,且,最後分散在不同公司, (甚至部分人員失聯:p)
如果有後續擴充,在整合測試會多一些額外不方便或難度.
※ 引述《nedbob (狗腿)》之銘言：
: 其實最大的問題是 TEST 有做好嗎
: 最基本的壓力測試都沒測試過......
: 就敢把這套系統拿來用......
: 這已經不是系統演算法的問題了吧
: 如果有好好的去做 TEST 的那幾個步驟 black white alpha beta...等
: 如果這套系統禁得起測試 但是發現他的效能低落
: 不管怎麼修改都沒辦法達到應該要的效能時
: 才要去重新考慮這套系統該改由什麼演算法去實作吧
: 今天高鐵的系統 很明顯的就是BUG沒改好 發生重複訂位
: 又不是說定一張票要等10幾分鐘才可以定這種效能問題
: 而且抓BUG應該在 TEST 就被抓出來 很明顯的就是 TEST 沒做好
: 結果大家開始戰起演算法等等等.......= =|||
: 目前大家的反應好像就是
: 有一個人寫訂票系統寫好 他用最笨的方法下去寫 程式碼很醜 也沒用資料結構
: 只是程式某個地方寫錯 執行時有點問題會發生重複訂位
: 他請你幫他看問題出在哪...... 結果你卻直接跟他說應該要把演算法整個換掉
: 巴拉巴拉一大堆 其實只要改掉一個小地方 這支程式就能正常運作
: 高鐵目前問題有必要去討論到要用哪一套演算法嗎.....
: 不一定高鐵繼續用它的系統 抓到BUG小改個地方 就能把所有問題解決掉
: 那講了一大堆 演算法 高演 的有意義嗎?? 感覺大家真是愛戰 每次都不知道戰到哪去
: 而且一開始原PO就是提問說做了多少的 QA testing 結果就變成了怎麼實作...= =|||
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 219.80.134.153