R08 支援專案所見(5)──遇例外就時間失控

在專案裡除了開發功能與除錯外，最耗費時間的莫過於臨時有狀況發生時要去追查相關資訊作進一步分析了。曾經有的經驗是：系統上線後大致都正常，但是在某段時間裡交易執行的時間是正常時的五倍到十倍。

客戶非常在意頻寬的使用與執行的效率，因此要求我們清查出問題那幾天裡每個交易執行與連線所花的時間；Log File一如平時所見，整個系統有四個伺服器，每個伺服器一天有50 MB以上的資料，而且還要加上數個Client的Log File。記錄的查看很容易，只要找出範圍再逐一過濾；但是客戶要的是全部資料耶！全部看完那禮拜就不用做別的事了。

我當然沒有去看內容，而寫程式判別Log File內特殊的關鍵字取出我所要的資訊存到CSV類型的檔案裡，再藉由排序的功能找出最耗時間交易的全部資訊再作分析。這個處理程式我寫了約三個工作天，但好處是未來任何時候的記錄檔拿回來後，只需要十分鐘就可以取得所有交易的內容作排序與解讀。

時間的失控主要是因為原先放置的東西沒有管理。如果今天的Log File內容不是有順序的邏輯，那麼不可能寫出轉換的工具程式；如果寫工具程式時沒有考慮Log File內交易記錄的全部屬性，那麼在日後客戶另外要求要看指定Client的所有執行交易代號統計時，還得另外再花時間撰寫。

例外，是臨時需要的資訊是原先的設計沒有規畫進去的，臨時為了解決那些例外的需要得花非常多的時間去處理。降低例外的影響有兩個原則：擴大一開始的設計範圍儘可能容納更多考慮得到的例外；另外就是保持設計的彈性，在例外發生時可以快速地將之包含進來卻沒有太大的風險。