2010/05/20

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」!


0 意見 :

張貼留言