[請益] 業界遇到這種bug該怎麼處理?

why304208/26 13:27買乖乖

DrTech08/26 13:27沒正常的Log可分析？

DrTech08/26 13:29正常有做exception與log處理，沒收到訊息會查到怎麼復現。

alihue08/26 13:38當然是想辦法 reproducing。當然基本功的程式要寫好，err

alihue08/26 13:38or handling 做足。此外訊息要做成驗證機制，對方可收到

alihue08/26 13:38才算完整傳送（看訊息如何設計）。

abccbaandy08/26 14:04就不理阿...無法重現的bug沒有修的必要XD

testPtt08/26 14:12通常是沒驗證有沒有傳成功

hobnob08/26 14:16如果無法重現但不影響軟體功能，就加log跟try catch補強程

hobnob08/26 14:16式就夠了

aaa123413608/26 14:24偶發就先記log，看之後有沒有辦法找出問題

qwe7030208/26 14:25沒有error的UIUX bug也只能想辦法重現，或是猜猜看code

qwe7030208/26 14:25哪一段有可能造成這個問題(簡稱通靈)

longlyeagle08/26 14:35沒辦法reproduce 就只能想辦法讓下次發生時能記錄到

DrTech08/26 14:37Log 的輸出，Debug 的輸出可以寫在console ，上線後，建議

longlyeagle08/26 14:37加log是一種 還有其他能用的都加一加

DrTech08/26 14:37上線後是寫在file才能追蹤。

giacch08/26 14:41你就讓聊天室 每分鐘重新整理一次 不就解決了?

Lomonosov08/26 14:41sentry

OriginStar08/26 15:01看bug嚴重性與修正的成本，每個bug當然也有它的權重

OriginStar08/26 15:02若客戶沒發現就留個紀錄或報告主管有這種情況讓主管

OriginStar08/26 15:03決定看要不要修

MoonCode08/26 15:06

ura121008/26 15:10先記著吧，或是報QA，很有可能不是聊天室本身的問題

guest071008/26 16:02定義哪些問題需要處理 + 做處理機制 然後定期回顧

bnd032708/26 17:46如果是你自己做的其實可以先推測是哪一段出問題

bnd032708/26 17:46然後在那一段動手腳看能不能增加重現機率

winnie83092508/26 17:46怎麼覺得這篇有既視感XDDD

single456508/26 18:25建議是先紀錄給QA，讓QA後續追蹤

k79897686908/26 19:06不重要 根本不用理

kirin02108/26 19:19感覺就是websocket一時斷掉，重整後重連回來

EKman08/26 19:24等新人來當作他的試用期考核題目

arcade042508/26 20:05怎麼跟前陣子的 10% 那篇有點像

iamshiao08/26 20:16沒頭緒就呈報，看主管要不要追。 其實工作久了就會對成

iamshiao08/26 20:16本比較有意識，不會像剛出來做那麼糾結在個別的問題

LoveMoon08/26 20:22有使用者上 issue 再說…

peter9808/26 22:20個人覺得不重要 除非你沒其他事情做

kurtsgm08/26 22:53在bug tracking system上寫unable to reproduce然後切掉

viper970908/26 23:51這種大部分是埋log~不過感覺很可能不是聊天室的問題+1

diabolica08/27 00:04沒差

saqwedcxz08/27 01:38兩年來只被發現一次的bug然後還無法重現，正常都放著吧

qss0508/27 08:09就算User反應，但照他的方式沒辦法重現，而且只有一次的話

qss0508/27 08:09，通常都會說再觀察吧，畢竟你做不出異常也沒辦法處理

hduek15308/27 09:39實務上這種傳說bug如果沒有頭緒就是包一包觀察吧

Csir08/27 09:46有可能是封包掉嗎

DrTech08/27 10:09封包掉，正常寫都很容易攔截到exception，原文不知道怎麼

DrTech08/27 10:09做的。

WaterLengend08/27 11:27都無法描述跟復現了，頂多記下來下次有發現再說

GoalBased08/27 15:23具體情況具體分析，你的話我覺得找個熟聊天室功能的人

GoalBased08/27 15:23看一下你的code就能抓到

ChungLi556608/27 19:02你們傳訊息沒有留文本紀錄？至少要留10天吧

overhead08/28 07:21看關鍵程度和人力成本，決定是否維修。很關鍵的應用，

overhead08/28 07:21派出最強老鳥修幾個月。相反的，不理它。

lchcoding08/28 11:27如果我做為你的客戶方

lchcoding08/28 11:27我應該會加一個測試案例如下

lchcoding08/28 11:271.請找一台桌上型電腦，RJ45

lchcoding08/28 11:27網路線為唯一對外通道

lchcoding08/28 11:27（若有無線網路，請都先關閉）,

lchcoding08/28 11:27開啟瀏覽器，此時要能正常瀏覽

lchcoding08/28 11:27任一你熟悉的網頁.拔掉RJ45,

lchcoding08/28 11:27此時再refresh瀏覽網頁時，

lchcoding08/28 11:27應該報錯,無法瀏覽網頁.

lchcoding08/28 11:272.重新接回RJ45,進入聊天室，

lchcoding08/28 11:27找朋友聊天，此時訊息-收/發

lchcoding08/28 11:27應該都要正常.

lchcoding08/28 11:273.拔掉RJ45, 此時訊息應該

lchcoding08/28 11:27發不出去，也收不進來

lchcoding08/28 11:27（請用其他訊息工具確認）

lchcoding08/28 11:274.重新接回RJ45,等侯1分鐘，

lchcoding08/28 11:27聊天室應該在已收/發訊息

lchcoding08/28 11:27無損失的情況下，恢復訊息收/發正常.

lchcoding08/28 11:275.［系統強健性測試］.結束

lchcoding08/28 11:28雖然這是強制性斷線，

lchcoding08/28 11:28但應該也能cover你遇到的狀況

lchcoding08/28 11:29如果你很有實驗精神，

lchcoding08/28 11:29走進機房，隨便找一台路由

lchcoding08/28 11:29或 Hub,然後挑一條網路線

lchcoding08/28 11:29拔掉再插回去.那麼剛剛已經

lchcoding08/28 11:29經過這一條網路線建立連線

lchcoding08/28 11:29的Client,server 兩端遇到的現象

lchcoding08/28 11:29就會跟你有九成像了

lchcoding08/28 11:29只要中間轉接的硬體足夠多，

lchcoding08/28 11:29server 會以為連線還正常，

lchcoding08/28 11:29照常轉發訊息，但訊息永遠

lchcoding08/28 11:29到不了client 端.

lchcoding08/28 11:29client端會以為連線還正常

lchcoding08/28 11:29不會產生已斷線的error

jej08/28 13:04看你的聊天室用什麼協定阿

jej08/28 13:04這關乎到補救方式 不然你要別人通靈嗎

jej08/28 13:04還有訊息的發出 都要有log阿 這不是基本的嗎？

jej08/28 13:04就算ap沒做 也會有bright要作

jej08/28 13:04看你的內文看不出來要從何debug起

abraxas08/28 14:57重要度太低完全排不進時程

f75050208/30 18:15寫壓測程式跑看看，如果有發生過跑一下就可以收log了吧

abola92109/12 23:311. 開issue記錄發生了什麼事。2. 等有空或是再次發生

abola92109/12 23:323. 想辦法復現bug。4. 動手除錯 or 忘了他