最近开发一个通讯软件
有个闪退的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%都随意