gipi的學習筆記-經營管理、數據思考、終身學習

好前一陣子接手處理一個客訴案件，案子在前期開發、中期測試、後期驗收過程中都沒有問題，案子也被順利的交付了，但當客戶使用後，常常在某些時刻會跳出error message，一下子是資料匯轉失敗、一下子是價格計算不正確、一下子又是資料沒有正確的被join出來....怪怪的問題都隨著系統上線而一一浮現。

剛接手處理這個case的時候，一聽完整個問題描述，很直覺得就想到，這個鐵定是資料處理上出了問題了，且出問題的點，肯定是在maintain主檔資料的那幾支程式，調出那幾支程式，開始進行boundary test，針對每個欄位進行資料的輸入，在數值欄位輸入過大的值、輸入英文、輸入中文；在日期欄位輸入2009/2/31、輸入英文、輸入中文....

依以上的測試方式，就發現果然有些欄位是沒有做準確的格式驗證的，接著叫出資料表中的資料做確認，發現某個數值欄位中存了英文、空白；某些日期欄位中存了2009/2/31....

上頭是其中一個例外發生的原因，而日期欄位之所以可以存2009/2/31，原因是他的資料欄位是char型態，不是DateTime；最後資料join不到的原因則是因為同一個資料表，某個欄位的值有時是空白，有時候是null，沒有一致性。

大致分析完整個問題的狀況後，我問PM想要怎麼處理這個問題，他說有辦法從後面的程式去防止這些問題嗎？我說不可能，因為使用者到底會輸入哪些東西你根本無法預測，如何防止，我建議把maintain主檔的所有程式都加入正確的格式檢查，才能杜絕這個問題，稍微分析一下，其實我們可以將資料庫作為另一種系統整合的縮影，A程式輸入資料，B程式去取得資料，兩者之間的關聯來自資料庫，所以說資料庫是兩者間的橋樑一點也沒錯，既然是橋梁，那就充分扮演橋樑的角色就好囉。

舉例來說：在路上我們可能會看到這樣的交通號誌，告知前面路面減縮，且禁止大貨車進入，若強行進入，最後會無法繼續前進。

在前例中，我們無法限制大卡車進入路寬只有3M的道路上，所以後續衍生的法律問題或者安全問題就出現了，正確的做法是在路面縮減前的雙叉口，就應該透過拒馬將寬度大於3M的車輛擋住，讓它無法通行，後續的問題就不會被觸發了；而在程式中，做法也是一樣，我們不是從後面的程式去挽救，而是該守住第一關，在使用者輸入資料時就進行格式驗證，不要讓不正確的資料被放進資料庫中，只要我們能確保資料是正確的，後續不管是B、C、D等等程式的使用，都不用擔心例外的錯誤狀況會出現了。

軟體設計的概念跟多數科學的概念很相似，只要能防範例外狀況，要收斂問題就會變的簡單多了，前幾天看到hatelove兄提到的4/31號的case，突然想到自己之前遭遇到的這個case，所以提出來給大家參考參考。

游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。