作者banana2014 (香蕉共和國)
看板Soft_Job
標題[請益] 業界遇到這種bug該怎麼處理?
時間Fri Aug 26 13:24:20 2022
我大概在兩年前左右做了一個網頁版的聊天室
約莫上個月的時候，我無意間發現了一個bug
那個bug是對方已經傳了一個新訊息給我，但我這邊卻完全沒收到他傳給我的新訊息
但等我重新整理聊天室頁面之後，那個bug就從此徹底銷聲匿跡了
而且從兩年前到bug發生當時的那段時間以及bug發生當時至今這段時間，用起來都很正常
也就是說那個bug只在上個月那一次發生之後就再也沒被我看到了
雖然我不是IT業界的專業程式設計師
不過我想問一下：
當遇到這種程式已寫了兩年以上才難得出現過一次算是有點嚴重的bug被你發現到了
通常專業的都怎麼處理?
因為這樣的bug或許很難刻意的被製造出來，所以幾乎只能靠運氣碰碰看了
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.226.110.67 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1661491462.A.11E.html
1F：推 why3042: 買乖乖 08/26 13:27
2F：→ DrTech: 沒正常的Log可分析？ 08/26 13:27
其實我當時在發現該bug時沒有開console分析
等我發現並看到該bug時已經來不及了
console沒有記錄到
有個難處是，我不可能每次用這個聊天室時，都要特別坐到電腦桌前，打開電腦開console去看吧
有時候可能只是用個手機隨便進一下聊天室用用看
結果那個bug就「無意間」跑出來的
※ 編輯: banana2014 (36.226.110.67 臺灣), 08/26/2022 13:31:51
3F：→ DrTech: 正常有做exception與log處理，沒收到訊息會查到怎麼復現。 08/26 13:29
對了，其實並不是每個bug都是以error的形式出來的
只要結果和畫面是不符合期待的，應該都被歸類作bug
所以即使程式有寫try...catch
bug的出現也不一定會跳出error log讓你知道
這也是我覺得處理起來最棘手的bug之一
因為它根本連錯誤訊息都不會跳出來讓你知道
※ 編輯: banana2014 (36.226.110.67 臺灣), 08/26/2022 13:35:06
※ 編輯: banana2014 (36.226.110.67 臺灣), 08/26/2022 13:39:40
4F：→ alihue: 當然是想辦法 reproducing。當然基本功的程式要寫好，err 08/26 13:38
5F：→ alihue: or handling 做足。此外訊息要做成驗證機制，對方可收到 08/26 13:38
6F：→ alihue: 才算完整傳送（看訊息如何設計）。 08/26 13:38
7F：推 abccbaandy: 就不理阿...無法重現的bug沒有修的必要XD 08/26 14:04
8F：→ testPtt: 通常是沒驗證有沒有傳成功 08/26 14:12
9F：推 hobnob: 如果無法重現但不影響軟體功能，就加log跟try catch補強程 08/26 14:16
10F：→ hobnob: 式就夠了 08/26 14:16
11F：推 aaa1234136: 偶發就先記log，看之後有沒有辦法找出問題 08/26 14:24
12F：推 qwe70302: 沒有error的UIUX bug也只能想辦法重現，或是猜猜看code 08/26 14:25
13F：→ qwe70302: 哪一段有可能造成這個問題(簡稱通靈) 08/26 14:25
14F：推 longlyeagle: 沒辦法reproduce 就只能想辦法讓下次發生時能記錄到 08/26 14:35
15F：→ DrTech: Log 的輸出，Debug 的輸出可以寫在console ，上線後，建議 08/26 14:37
16F：→ longlyeagle: 加log是一種 還有其他能用的都加一加 08/26 14:37
17F：→ DrTech: 上線後是寫在file才能追蹤。 08/26 14:37
18F：推 giacch: 你就讓聊天室 每分鐘重新整理一次 不就解決了? 08/26 14:41
19F：推 Lomonosov: sentry 08/26 14:41
20F：推 OriginStar: 看bug嚴重性與修正的成本，每個bug當然也有它的權重 08/26 15:01
21F：→ OriginStar: 若客戶沒發現就留個紀錄或報告主管有這種情況讓主管 08/26 15:02
22F：→ OriginStar: 決定看要不要修 08/26 15:03
23F：噓 MoonCode: 08/26 15:06
24F：推 ura1210: 先記著吧，或是報QA，很有可能不是聊天室本身的問題 08/26 15:10
25F：推 guest0710: 定義哪些問題需要處理 + 做處理機制 然後定期回顧 08/26 16:02
26F：推 bnd0327: 如果是你自己做的其實可以先推測是哪一段出問題 08/26 17:46
27F：→ bnd0327: 然後在那一段動手腳看能不能增加重現機率 08/26 17:46
28F：推 winnie830925: 怎麼覺得這篇有既視感XDDD 08/26 17:46
29F：推 single4565: 建議是先紀錄給QA，讓QA後續追蹤 08/26 18:25
30F：推 k798976869: 不重要 根本不用理 08/26 19:06
31F：→ kirin021: 感覺就是websocket一時斷掉，重整後重連回來 08/26 19:19
32F：推 EKman: 等新人來當作他的試用期考核題目 08/26 19:24
33F：推 arcade0425: 怎麼跟前陣子的 10% 那篇有點像 08/26 20:05
34F：→ iamshiao: 沒頭緒就呈報，看主管要不要追。 其實工作久了就會對成 08/26 20:16
35F：→ iamshiao: 本比較有意識，不會像剛出來做那麼糾結在個別的問題 08/26 20:16
36F：推 LoveMoon: 有使用者上 issue 再說… 08/26 20:22
37F：→ peter98: 個人覺得不重要 除非你沒其他事情做 08/26 22:20
38F：推 kurtsgm: 在bug tracking system上寫unable to reproduce然後切掉 08/26 22:53
39F：推 viper9709: 這種大部分是埋log~不過感覺很可能不是聊天室的問題+1 08/26 23:51
40F：→ diabolica: 沒差 08/27 00:04
41F：→ saqwedcxz: 兩年來只被發現一次的bug然後還無法重現，正常都放著吧 08/27 01:38
42F：→ qss05: 就算User反應，但照他的方式沒辦法重現，而且只有一次的話 08/27 08:09
43F：→ qss05: ，通常都會說再觀察吧，畢竟你做不出異常也沒辦法處理 08/27 08:09
44F：推 hduek153: 實務上這種傳說bug如果沒有頭緒就是包一包觀察吧 08/27 09:39
45F：推 Csir: 有可能是封包掉嗎 08/27 09:46
46F：→ DrTech: 封包掉，正常寫都很容易攔截到exception，原文不知道怎麼 08/27 10:09
47F：→ DrTech: 做的。 08/27 10:09
48F：推 WaterLengend: 都無法描述跟復現了，頂多記下來下次有發現再說 08/27 11:27
49F：→ GoalBased: 具體情況具體分析，你的話我覺得找個熟聊天室功能的人 08/27 15:23
50F：→ GoalBased: 看一下你的code就能抓到 08/27 15:23
51F：→ ChungLi5566: 你們傳訊息沒有留文本紀錄？至少要留10天吧 08/27 19:02
52F：推 overhead: 看關鍵程度和人力成本，決定是否維修。很關鍵的應用， 08/28 07:21
53F：→ overhead: 派出最強老鳥修幾個月。相反的，不理它。 08/28 07:21
54F：→ lchcoding: 如果我做為你的客戶方 08/28 11:27
55F：→ lchcoding: 我應該會加一個測試案例如下 08/28 11:27
56F：→ lchcoding: 1.請找一台桌上型電腦，RJ45 08/28 11:27
57F：→ lchcoding: 網路線為唯一對外通道 08/28 11:27
58F：→ lchcoding: （若有無線網路，請都先關閉）, 08/28 11:27
59F：→ lchcoding: 開啟瀏覽器，此時要能正常瀏覽 08/28 11:27
60F：→ lchcoding: 任一你熟悉的網頁.拔掉RJ45, 08/28 11:27
61F：→ lchcoding: 此時再refresh瀏覽網頁時， 08/28 11:27
62F：→ lchcoding: 應該報錯,無法瀏覽網頁. 08/28 11:27
63F：→ lchcoding: 2.重新接回RJ45,進入聊天室， 08/28 11:27
64F：→ lchcoding: 找朋友聊天，此時訊息-收/發 08/28 11:27
65F：→ lchcoding: 應該都要正常. 08/28 11:27
66F：→ lchcoding: 3.拔掉RJ45, 此時訊息應該 08/28 11:27
67F：→ lchcoding: 發不出去，也收不進來 08/28 11:27
68F：→ lchcoding: （請用其他訊息工具確認） 08/28 11:27
69F：→ lchcoding: 4.重新接回RJ45,等侯1分鐘， 08/28 11:27
70F：→ lchcoding: 聊天室應該在已收/發訊息 08/28 11:27
71F：→ lchcoding: 無損失的情況下，恢復訊息收/發正常. 08/28 11:27
72F：→ lchcoding: 5.［系統強健性測試］.結束 08/28 11:27
73F：→ lchcoding: 雖然這是強制性斷線， 08/28 11:28
74F：→ lchcoding: 但應該也能cover你遇到的狀況 08/28 11:28
75F：→ lchcoding: 如果你很有實驗精神， 08/28 11:29
76F：→ lchcoding: 走進機房，隨便找一台路由 08/28 11:29
77F：→ lchcoding: 或 Hub,然後挑一條網路線 08/28 11:29
78F：→ lchcoding: 拔掉再插回去.那麼剛剛已經 08/28 11:29
79F：→ lchcoding: 經過這一條網路線建立連線 08/28 11:29
80F：→ lchcoding: 的Client,server 兩端遇到的現象 08/28 11:29
81F：→ lchcoding: 就會跟你有九成像了 08/28 11:29
82F：→ lchcoding: 只要中間轉接的硬體足夠多， 08/28 11:29
83F：→ lchcoding: server 會以為連線還正常， 08/28 11:29
84F：→ lchcoding: 照常轉發訊息，但訊息永遠 08/28 11:29
85F：→ lchcoding: 到不了client 端. 08/28 11:29
86F：→ lchcoding: client端會以為連線還正常 08/28 11:29
87F：→ lchcoding: 不會產生已斷線的error 08/28 11:29
88F：→ jej: 看你的聊天室用什麼協定阿 08/28 13:04
89F：→ jej: 這關乎到補救方式 不然你要別人通靈嗎 08/28 13:04
90F：→ jej: 還有訊息的發出 都要有log阿 這不是基本的嗎？ 08/28 13:04
91F：→ jej: 就算ap沒做 也會有bright要作 08/28 13:04
92F：→ jej: 看你的內文看不出來要從何debug起 08/28 13:04
93F：推 abraxas: 重要度太低完全排不進時程 08/28 14:57
94F：噓 f750502: 寫壓測程式跑看看，如果有發生過跑一下就可以收log了吧 08/30 18:15
95F：推 abola921: 1. 開issue記錄發生了什麼事。2. 等有空或是再次發生 09/12 23:31
96F：→ abola921: 3. 想辦法復現bug。4. 動手除錯 or 忘了他 09/12 23:32