推 why3042: 買乖乖 08/26 13:27
→ DrTech: 沒正常的Log可分析？ 08/26 13:27
→ DrTech: 正常有做exception與log處理，沒收到訊息會查到怎麼復現。 08/26 13:29
→ alihue: 當然是想辦法 reproducing。當然基本功的程式要寫好，err 08/26 13:38
→ alihue: or handling 做足。此外訊息要做成驗證機制，對方可收到 08/26 13:38
→ alihue: 才算完整傳送（看訊息如何設計）。 08/26 13:38
推 abccbaandy: 就不理阿...無法重現的bug沒有修的必要XD 08/26 14:04
→ testPtt: 通常是沒驗證有沒有傳成功 08/26 14:12
推 hobnob: 如果無法重現但不影響軟體功能，就加log跟try catch補強程 08/26 14:16
→ hobnob: 式就夠了 08/26 14:16
推 aaa1234136: 偶發就先記log，看之後有沒有辦法找出問題 08/26 14:24
推 qwe70302: 沒有error的UIUX bug也只能想辦法重現，或是猜猜看code 08/26 14:25
→ qwe70302: 哪一段有可能造成這個問題(簡稱通靈) 08/26 14:25
推 longlyeagle: 沒辦法reproduce 就只能想辦法讓下次發生時能記錄到 08/26 14:35
→ DrTech: Log 的輸出，Debug 的輸出可以寫在console ，上線後，建議 08/26 14:37
→ longlyeagle: 加log是一種 還有其他能用的都加一加 08/26 14:37
→ DrTech: 上線後是寫在file才能追蹤。 08/26 14:37
推 giacch: 你就讓聊天室 每分鐘重新整理一次 不就解決了? 08/26 14:41
推 Lomonosov: sentry 08/26 14:41
推 OriginStar: 看bug嚴重性與修正的成本，每個bug當然也有它的權重 08/26 15:01
→ OriginStar: 若客戶沒發現就留個紀錄或報告主管有這種情況讓主管 08/26 15:02
→ OriginStar: 決定看要不要修 08/26 15:03
噓 MoonCode: 08/26 15:06
推 ura1210: 先記著吧，或是報QA，很有可能不是聊天室本身的問題 08/26 15:10
推 guest0710: 定義哪些問題需要處理 + 做處理機制 然後定期回顧 08/26 16:02
推 bnd0327: 如果是你自己做的其實可以先推測是哪一段出問題 08/26 17:46
→ bnd0327: 然後在那一段動手腳看能不能增加重現機率 08/26 17:46
推 winnie830925: 怎麼覺得這篇有既視感XDDD 08/26 17:46
推 single4565: 建議是先紀錄給QA，讓QA後續追蹤 08/26 18:25
推 k798976869: 不重要 根本不用理 08/26 19:06
→ kirin021: 感覺就是websocket一時斷掉，重整後重連回來 08/26 19:19
推 EKman: 等新人來當作他的試用期考核題目 08/26 19:24
推 arcade0425: 怎麼跟前陣子的 10% 那篇有點像 08/26 20:05
→ iamshiao: 沒頭緒就呈報，看主管要不要追。 其實工作久了就會對成 08/26 20:16
→ iamshiao: 本比較有意識，不會像剛出來做那麼糾結在個別的問題 08/26 20:16
推 LoveMoon: 有使用者上 issue 再說… 08/26 20:22
→ peter98: 個人覺得不重要 除非你沒其他事情做 08/26 22:20
推 kurtsgm: 在bug tracking system上寫unable to reproduce然後切掉 08/26 22:53
推 viper9709: 這種大部分是埋log~不過感覺很可能不是聊天室的問題+1 08/26 23:51
→ diabolica: 沒差 08/27 00:04
→ saqwedcxz: 兩年來只被發現一次的bug然後還無法重現，正常都放著吧 08/27 01:38
→ qss05: 就算User反應，但照他的方式沒辦法重現，而且只有一次的話 08/27 08:09
→ qss05: ，通常都會說再觀察吧，畢竟你做不出異常也沒辦法處理 08/27 08:09
推 hduek153: 實務上這種傳說bug如果沒有頭緒就是包一包觀察吧 08/27 09:39
推 Csir: 有可能是封包掉嗎 08/27 09:46
→ DrTech: 封包掉，正常寫都很容易攔截到exception，原文不知道怎麼 08/27 10:09
→ DrTech: 做的。 08/27 10:09
推 WaterLengend: 都無法描述跟復現了，頂多記下來下次有發現再說 08/27 11:27
→ GoalBased: 具體情況具體分析，你的話我覺得找個熟聊天室功能的人 08/27 15:23
→ GoalBased: 看一下你的code就能抓到 08/27 15:23
→ ChungLi5566: 你們傳訊息沒有留文本紀錄？至少要留10天吧 08/27 19:02
推 overhead: 看關鍵程度和人力成本，決定是否維修。很關鍵的應用， 08/28 07:21
→ overhead: 派出最強老鳥修幾個月。相反的，不理它。 08/28 07:21
→ lchcoding: 如果我做為你的客戶方 08/28 11:27
→ lchcoding: 我應該會加一個測試案例如下 08/28 11:27
→ lchcoding: 1.請找一台桌上型電腦，RJ45 08/28 11:27
→ lchcoding: 網路線為唯一對外通道 08/28 11:27
→ lchcoding: （若有無線網路，請都先關閉）, 08/28 11:27
→ lchcoding: 開啟瀏覽器，此時要能正常瀏覽 08/28 11:27
→ lchcoding: 任一你熟悉的網頁.拔掉RJ45, 08/28 11:27
→ lchcoding: 此時再refresh瀏覽網頁時， 08/28 11:27
→ lchcoding: 應該報錯,無法瀏覽網頁. 08/28 11:27
→ lchcoding: 2.重新接回RJ45,進入聊天室， 08/28 11:27
→ lchcoding: 找朋友聊天，此時訊息-收/發 08/28 11:27
→ lchcoding: 應該都要正常. 08/28 11:27
→ lchcoding: 3.拔掉RJ45, 此時訊息應該 08/28 11:27
→ lchcoding: 發不出去，也收不進來 08/28 11:27
→ lchcoding: （請用其他訊息工具確認） 08/28 11:27
→ lchcoding: 4.重新接回RJ45,等侯1分鐘， 08/28 11:27
→ lchcoding: 聊天室應該在已收/發訊息 08/28 11:27
→ lchcoding: 無損失的情況下，恢復訊息收/發正常. 08/28 11:27
→ lchcoding: 5.［系統強健性測試］.結束 08/28 11:27
→ lchcoding: 雖然這是強制性斷線， 08/28 11:28
→ lchcoding: 但應該也能cover你遇到的狀況 08/28 11:28
→ lchcoding: 如果你很有實驗精神， 08/28 11:29
→ lchcoding: 走進機房，隨便找一台路由 08/28 11:29
→ lchcoding: 或 Hub,然後挑一條網路線 08/28 11:29
→ lchcoding: 拔掉再插回去.那麼剛剛已經 08/28 11:29
→ lchcoding: 經過這一條網路線建立連線 08/28 11:29
→ lchcoding: 的Client,server 兩端遇到的現象 08/28 11:29
→ lchcoding: 就會跟你有九成像了 08/28 11:29
→ lchcoding: 只要中間轉接的硬體足夠多， 08/28 11:29
→ lchcoding: server 會以為連線還正常， 08/28 11:29
→ lchcoding: 照常轉發訊息，但訊息永遠 08/28 11:29
→ lchcoding: 到不了client 端. 08/28 11:29
→ lchcoding: client端會以為連線還正常 08/28 11:29
→ lchcoding: 不會產生已斷線的error 08/28 11:29
→ jej: 看你的聊天室用什麼協定阿 08/28 13:04
→ jej: 這關乎到補救方式 不然你要別人通靈嗎 08/28 13:04
→ jej: 還有訊息的發出 都要有log阿 這不是基本的嗎？ 08/28 13:04
→ jej: 就算ap沒做 也會有bright要作 08/28 13:04
→ jej: 看你的內文看不出來要從何debug起 08/28 13:04
推 abraxas: 重要度太低完全排不進時程 08/28 14:57
噓 f750502: 寫壓測程式跑看看，如果有發生過跑一下就可以收log了吧 08/30 18:15
推 abola921: 1. 開issue記錄發生了什麼事。2. 等有空或是再次發生 09/12 23:31
→ abola921: 3. 想辦法復現bug。4. 動手除錯 or 忘了他 09/12 23:32