20100520-心情-把事情想的太簡單了！

今天在客戶那邊，一如往常地處理Bug。
有一個單子，是在昨天就把它結掉了，

看那單子的描問題述，認為，
就是在它Alert出"那個訊息"後，不該讓 某Button Enable。

這種小兒科的東西，一下子就把它處理掉了。

今天，Leader要上版到正式機。
因為另兩個tester沒空測這問題，由Leader自已測試。

「Howard，你這問題有沒有處理？怎麼還是一樣？？
那個Button還是可以按呀」

呀？我已處理過了呀，怎麼一回事？

結果是，它問題描述的「語意」我把它解讀錯了！
事實上是本來這描述就很容易被解讀成那樣(=.=a~我那時推測了好一陣子)
但，這種事，應該是要去問Leader它"正確"意思是什麼！
而不該在那自已推測

「當如果是"已傳輸"下的查詢，要把那"審核"的Button 要 Disable」
因為"已傳輸"它表示的意思就是"已審核"
所以再次執行"審核"，才會Alert 出那訊息。
而我看圖解意，誤解成在 Alert 後 Disable；
他們想要的，是在Alert前就要Disable。

後來，再次和Leader確認，是在"已傳輸"的查詢狀況下，都要Disable這Button嗎？？
他說，是的！

OK~~方向確認了，就開始把它處理掉。
改好，Check In，寫問題描述、壓版本、再寄Mail告知，
再給Leader 測一次。

這時，時間已經是五點半了！(六點半下班)

「Howard，要我測完才可以走」
她事前「預告」一下。

我休息放鬆一下，等著他的測試結果。
應該是OK的。

「Howard，不對呀！你看，這樣操作，還是可以按"審核"button呀！」

呀？什麼鬼呀？

它是有做RadioButton做查詢條件的切換；它是長這樣的
O ALL    O未傳輸    O已傳輸

「當在 O已傳輸 下的查詢，"審核"的button都要Disable」
是的，這個我已經做到了！

但當 它 選 「O ALL」 時，若資料列，只有"已傳輸" 資料時，Button也要Disable！
(這什麼鬼呀，那我要再那兒判斷？)

「喔，好」，這時時間已是6:20分了！

程式是人寫的，方法也絕對是要自已找的！

找出它的"差異條件"，在它取出資料後，再判斷資料裡有沒有「未傳輸」資料

嗯，寫好，測過，OK，上版 ，改寫問題描述，壓版本，寄Mail
(對這程序越來越上手)~OK，時間6:40分左右。

這次應該是OK，再來就等她測試結果。

「Howard，不對呀，你看，我查詢全部，裡面有[未傳輸]/[已傳輸]資料
我按「審核」之後，還是會跳出那Alert字串呀！這樣User會誤會ooxxx」

頭腦開始一連串的Debug，問題出在那？
會Alert？就表示沒資料？但沒有勾選已傳輸資料呀？為什麼還Alert？

好~~開始查原因！ (嗚~今天不用下班了)

慘了，我要怎樣像Leader一樣有麼多筆資料可以用？
我要怎麼建假資料？？
好~~從它 Query的Oracle 條件著手！

媽呀~~組一串查詢Query可以長到4~50行
Join、子查詢，一堆的全來了
這之前就知道，但我可以有辦法把它避掉
這次，就不行了，我要看它 取什麼資料，
OK~
自已推說它的關鍵 欄位是那些、那些要有值
再去update Oracle資料
~~~還是不行~做不出它的假資料
(Query太長，真的只能憑功力去猜它的Key在那？)

實在沒辦法了，就問一下Leader說
要怎麼 才能做出 可以「審核」的資料？？
要去改Table的那些資料？？

「我是直接在網站，由那個[..報表查詢]那去Upload資料
這樣，就可以建出可以「審核」的資料」
呀~~原來是這樣就好啦 =.=a

這時，就完全凸顯出我的「商業邏輯」弱到不行
只可以 由 技術(程式) 去推它的Bug
見一個影，開一次槍！
甚至我最近改完的Bug，我都記不起來，我改過了那個"功能"
完全就是"Coding"看世界。

後來「報表查詢」Upload資料，這方式，只有一筆資料，
就被我測試用完了。

再來呢？

就再問「要怎樣建「報表查詢」Upload的測試資料？」
Leader就說「這很複雜~你要...ooxoxo...然後再用Batch那支程式跑」
吧啦吧拉一堆流程~~(但現在已經八點了)

「你明天再請Jennifer(Tester)幫你建資料，你就先回家明天再來弄」

唉~~~這一次，給我好大的「反省」

一是，問題的 延伸性推測 不夠，甚至是不太敢問。
如果厲害一點，一開始「題意」就要弄清楚
在知道「已傳輸」的查詢下，「審核」Button要Disable
就要推說~ 「ALL」的查詢，是否有要跟「已傳輸」一樣邏輯？
(因為 未傳輸 可能沒有資料)
在「資料混雜」下的審核，是否會跳出Alert這狀態？

要學著 "全方向" 的 "策略" 思考 ，把多種狀況考慮進去。

二是，我不應該那麼「技術面」
在做「技術面」的問題處理時，要弄懂它背後的「商務邏輯」
代表著什麼？
讓自已記下它的「商務邏輯」，
而不單單只是「我改了這個那個的」這種模糊說辭。
懂得一塊塊商務邏輯，到時才會有辦法更瞭解整體系統架構。

在這客戶這...
已經是 2個禮拜 又4天了！
前2個禮拜有人帶，會教我一些商務邏輯。
這4天，自已摸索，Bug處理速度是不弱，但就是懂的好「空虛」

該問的還是要問，
不然我的問題會堆一堆。

最後~~~我這裡的Leader，讓我有點怕的人，
也就是此專案的頭頭/負責人

她的英文名............叫作「Jessica」！