找到根因，才能從根本上解決問題
源自我參與的一個項目在使用者那裡出了bug，當然非我的改動引發，是之前處理資料未考慮到異常。
一、Bug描述
=出口1flow1-出口2flow2，優化比例=優化資料/出口1flow1。
bug表象是優化資料為負值，優化比例為負值。使用者一看還了得，還不如不去優化？
二、Bug臨時補救方案
近幾年就跑出一回。是以，我們的方案是，當出口2flow2>出口1flow1的時候，就置出口2flow2 =出口1flow1。這樣就絕對不會出現優化數和優化比例為負數的情況。
三、Bug補救後仍存在隐患
1：所有上面的出口1、出口2的資料是從mysql資料庫中讀取的，包含合計資料。合計和應用1-9共用一套邏輯，是以導緻糾錯時，如果出現出口2比出口1大的情況，置出口2=出口1的資料。這樣就會出現出口2列的應用1-應用9的求和與出口2合計不等的隐患。
1：隻有出口2列對應的合計行出錯，真正的和應該等于應用1+…+應用9。想到的方案是不是從資料庫中讀取，而是進行應用1到應用9的求和。
1後的隐患：我們保證了不出現異常資料，保證求和正确，使用者看着沒有問題，但作為工程師，就要扒一扒為什麼會出現上面的異常資料？
四、找到根因
讨論分析發現，是我們的應用識别驅動問題出了問題，導緻講大量出口1的資料識别為出口2的資料。即是下圖的分類識别資料出了錯。
五、總結
很小很小的bug，但是帶來很大很大的災難性不可饒恕的問題，這種我們自身驗證和測試是幾年也跑不出這種異常資料的。但是，我們對異常的把控是做的遠遠不夠的，其實除了常用的除數為0的情況，對于這種優化資料良不能為負數的情況也必須敲響警鐘！
程式設計中要做出異常處理機制，或者跑出異常、或者列印錯誤日志，或者其他方法，但是一定要去做，要去處理，異常的場景考慮的越全面越好，異常的處理機制對應的越多越好。
謹記！
2014-9-21am10:30思于家中床前
作者：銘毅天下
轉載請标明出處