最近開發一個通訊軟體
有個閃退的bug自從上週被發現到之後就再也沒被觀察到
也就是這個bug的出現沒有規律性，只能靠碰運氣
出現機率也不高 (出現機率不到10%)
這也是我對這個bug感到煩惱的地方
如果各位遇到這樣性質的bug
你會怎麼去處理?
會去盡可能的鑽研，並且製造出這bug出現的可能嗎
還是會選擇直接忽略?

看有沒有人在追殺

不是你想不想修, 是你老闆想不想修, 而且10%很高了

所有動作做log, 之後再重點做更細的log, 直到能重現錯誤修好是你的能力 修不好是錢太少 XD

那就跟樓上一樣, 用開發版, log全寫, 直到能重現錯誤

log記得用try catch包掉, 免得為了log生出更多錯誤 慘...

主管叫你處理再處理 不然ㄧ起裝死就好 熱心主動又不會加薪 主動提要修而沒修好就是你的問題

我會選擇再也不寫 UI

10%很高了吧 1%可能ok

UI 的話八成是某種操作順序引起的.

就放著吧 就像蝦皮的app每天一堆bug沒在修 一堆人還不是照用

當然是盡快處理阿，但合不合進 release 看情況顆顆

看看薪水付到什麼程度吧

看能不能用自動化腳本重現搭配log，掛一晚總能重現吧就怕你的可遇不可求在高手眼中根本是定性行為

先看回報的使用者情境 配合log去判斷可能的因素阿再請QA試著模擬來抓bug

10%超高.....除非是不重要且要準備sunset的功能，

10%一定得修吧 超高欸

正常來說會有QA負責測觸發條件

10%你絕對每天都看得到

加log之後裝死看有沒有幾乎找到啊

看修這BUG的價值有沒有高到可以排進工作內

主動報告，主動承攬，修好這就是你的工作成績。

10%超高欸，怎麼會不可求呢，當工程師基本的機率概念要有吧

找QA幫忙？

google:空氣清淨機造成電腦當機 (負離子,原文有圖)同事有時要解跑72小時才會出現的bug

會吧，好奇嘛

90%機率出現的bug都不一定會修了 10%還真得很低

就在有關連的地方多寫log

連10%的概念都沒你跟我說你是工程師？

又讓我想到以前開自動腳本錄影的恐懼

10%很高好嗎

不過如果是不重要不賺錢的地方其實沒啥差

10% 超高應該是一定得修 QQ

10趴表示我今天開20次就閃退2次，我會掀桌

10%滿高的耶，感覺就多加log，然後測到它出現為止（？

10趴應該可以複製出來吧，萬分之一可能就要看是什麼，如果是車用，嚴重還得找出來

10%很高了== 我還遇過300次才出一次的bug

之前遇過類似的案例，在專案不趕的時候跟主管說我要修這個 bug。之後面試可以拿來說嘴。（團隊裡我主動跳出來修沒人知道原因的 bug）再美化 trace 的過程

10%閃退算嚴重吧，是會被留負評的bug

10%不可能複製不出來啦先檢查是不是多執行緒寫壞了

有的bug還只會在release才出錯

leak看一下吧八成搞鬼

10趴超高捏

10%超高 1萬人會有1000人跟你客訴抱怨 你受的了...?

只要可以用%來算的應該都會被追殺吧....

我會覺得原po提供的資訊太少不足判斷，問題描述也要加強XD

10%算不高？太誇張了。

我覺得原 Po 把 10% 這個敘述改掉比較好，看整體敘述其實沒有 10% 這麼嚴重，應該是用了快十天突然有一天在不明原因閃退了一次，但大部分人看到 10% 這個數字就像聞到血的鯊魚窮追猛打喊很高，顯示自己的優越但根本沒有要解決原po 問題的意思，也是蠻無聊的

不懂不要自己下comment，任何問題發生了就是一個問題，哪有分什麼嚴重不嚴重什麼可遇不可求，這個的心態在正常公司就慘了

你是不是對軟體開發沒啥概念啊

很簡單的評量順序 1.急嗎 2.重要嗎 3.有提升技術的價值嗎 4.有時間嗎 5.薪水滿意嗎每個人有不同的指標，每個指標的主觀判斷也不一樣，工作環境也帶來不同的影響我認為好的工程師的素養之一，隨著經驗跟機遇自然會形成獨有的判斷標準，對得起自己的心就好

10%蠻高的 就算在生產環境裡用log抓蟲也要用

這種閃避的垃圾也是可遇不可求。難怪人才很少渣一堆、難免難免。建議專職、不要害人害己！

如果遇到比較盡責的QA 應該會被卡死不能上線吧，這已然上升到對於工作的負責問題了

10%太高，不處理會被罵，1%就再看看

1%以內還可以考慮 10%幾乎就是天天都會發生

XD 淦好難，可能真的同一樓

對10%沒概念的工程師寫出來的bug只有10%發生率算是可接受了，畢竟他寫出來了

10%閃退聽起來超難用

掛載在debugger上,等bug

10%很高好嗎....你說1%以下那再看看

1%都高

用MLB這App 非常偶爾閃退我覺得根本沒差 重開就好了如果是遊戲類型會閃退 那一定會不想玩 所以還是看App類型決定閃退的嚴重性吧

哪來的菜雞 連10%的概念都沒有

看業務影響

10%很高了 算很好重製的問題萬分之一就是想辦法讓機率變高再來debug

如果你單一時間都有接這個產品 我是建議你就修好吧如果你同時間接很多產品,那可以先緩緩

1.Log有寫好嗎 2.有做壓力測試。3.memery profiling 看看是否有不正常變化。

。

操作10次發生1次？那很多阿 不過視情況bug->feature的處理也是有的

bug->feature 習慣成自然 讚

我不到1%就被提block，會被電的

基本就是log追啊 厲害點的就利用debugger追call stack

10%是高到恐怖了吧

要不公開軟體，讓鄉民測爆

其實不用這麼苛刻，不是每個產品都百萬用戶做產品很常花半年用高標準大量人力下去做最後投入市場 月增慘兮兮，沒幾個月就下線了我的意見是，非公司主力產品，活躍用戶低那你花心力在主力產品上能幫公司賺錢就好

除非專案上有更重要的項目要辦不然10%會被電出汁吧

Log全開 用腳本跑測到有啊

我們300次出現1次的都會被要求解決了

還是要解 客戶就是有辦法打到它

掛 crash report 把 exception 傳回來研究。也可以知道發生的機率多少。

取決於你的能力能否在有限時間內修掉而已就這麼簡單

要不要修是問主管吧

10% 隨便打都打得到欸

metrics 先觀察有沒有異常的，有很多異常是別的服務造成的聯鎖反應，個人抓錯經歷中這個最好用

10% 還是乖乖休掉

看這問題大不大

看問題大否，重要的可能1%都算嚴重，不重要的可能99%都隨意