從高鐵談大型公共建設軟體開發專案(下)

| | | | | | 66則回應

    

不要猜問題所在

高鐵售票系統不能符合使用者需求、以及系統無法正常運作等原因似乎很簡單，但是，長年軟體開發的經驗與專業卻告訴我：只站在表面上來看事情是不夠的，而要思考問題背後的問題。

有些人認為，高鐵售票系統會發生重覆劃位的問題，是因為資料庫設計上，沒有加上資料庫unique key來限制資料的唯一性，或是在確認交易完成前，並未加檢查同一個位置是否已被買走了（筆者認為，他大概指的是類似資料庫寫入時加入lock鎖定的機制）。

不過這樣的推論可能有問題。因為，據「可靠的馬路消息來源」指出，高鐵售票系統並未採用資料庫技術。因此，重覆訂票的問題與資料庫表格有沒有設unique key 或在交易過程中有沒有加入lock鎖定的機制是沒有關係的。

筆者想說的是，許多技術人員習於以自己所熟知的技術經驗，來尋求問題解答，卻未先去深入探討問題本身，相當令人憂心；這種做法常常會造成設計的盲目現象，當然不可能解決真正的問題。試想，如果我們沒辦法看清楚問題，對問題茫然，又怎能期待真正解決問題呢？

解決問題的心態

筆者認為，大型公共建設軟體專案在技術上的關鍵，並不在於技術本身，而是開發者心態問題，也就是開發者深入了解問題之後，選擇可用的技術，並加以不斷的調適、熟練的過程。大型公共建設專案常常不能單純只站在技術的著眼點來看事情，因為除了工程技術（engineering technology）觀點之外，軟體資訊系統往往是社會技術觀點（social technology）下的產物。如同前面所言及的，要兼顧不同關係人的期望與目標，問正確的問題，才能找到最適當的解決方案。

依據筆者的觀察，愈資深的技術人員在面臨軟體出現功能失常（failure）時，愈容易傾向於用猜測的方式來解決。可能是因為他們自認經驗豐富，問題應該不出於他們的經驗範圍之外，所以不管軟體出現的失常現象有多棘手，他們並不想花時間寫測試程式找出軟體的瑕疵（defect）。可能拜開發技術進步及開發工具的強大所賜，筆者近年來也常發現，一些新進的軟體開發者也有這種習慣猜問題來找答案的習慣。

筆者非常不認同這種處理軟體功能失常的態度，當有人尋求我的支援，協助他（她）找到程式bug的過程中，我都會提醒開發者：問題不要用猜的！我們當然可以假設問題，但必須要去求證，所以不要吝惜寫測試程式或加上程式執行過程的記錄（log）。

到底高鐵售票系統的重覆劃位問題，問題出在什麼地方呢？筆者並未參與其中，同時也不想妄加臆測；因為筆者相信，不管經驗有多麼豐富，我永遠不知道我所不知道的事情。不過，筆者卻知道，問題不要用猜的，而是要經由穩定及可見的觀察、假設後的求證、尋求問題的對策、最後再採取行動解決的過程，經驗往往是最不可靠的東西之一。態度才是決定技術得以成功的決定因素呀！