我大概在两年前左右做了一个网页版的聊天室
约莫上个月的时候，我无意间发现了一个bug
那个bug是对方已经传了一个新讯息给我，但我这边却完全没收到他传给我的新讯息
但等我重新整理聊天室页面之后，那个bug就从此彻底销声匿迹了
而且从两年前到bug发生当时的那段时间以及bug发生当时至今这段时间，用起来都很正常
也就是说那个bug只在上个月那一次发生之后就再也没被我看到了
虽然我不是IT业界的专业程式设计师
不过我想问一下：
当遇到这种程式已写了两年以上才难得出现过一次算是有点严重的bug被你发现到了
通常专业的都怎么处理?
因为这样的bug或许很难刻意的被制造出来，所以几乎只能靠运气碰碰看了
作者:
why3042 (yy)
2022-08-26 13:27:00买乖乖
作者:
DrTech (竹科管理处网军研发人员)
2022-08-26 13:27:00没正常的Log可分析？正常有做exception与log处理，没收到讯息会查到怎么复现。
作者:
alihue (wanda wanda)
2022-08-26 13:38:00当然是想办法 reproducing。当然基本功的程式要写好，error handling 做足。此外讯息要做成验证机制，对方可收到才算完整传送（看讯息如何设计）。
作者:
testPtt (测试)
2022-08-26 14:12:00通常是没验证有没有传成功
作者: hobnob (hobnob) 2022-08-26 14:16:00
如果无法重现但不影响软件功能，就加log跟try catch补强程式就够了
作者:
qwe70302 (为何一到90分就会输)
2022-08-26 14:25:00没有error的UIUX bug也只能想办法重现，或是猜猜看code哪一段有可能造成这个问题(简称通灵)
没办法reproduce 就只能想办法让下次发生时能记录到
作者:
DrTech (竹科管理处网军研发人员)
2022-08-26 14:37:00Log 的输出，Debug 的输出可以写在console ，上线后，建议
作者:
giacch 2022-08-26 14:41:00你就让聊天室 每分钟重新整理一次 不就解决了?
看bug严重性与修正的成本，每个bug当然也有它的权重若客户没发现就留个纪录或报告主管有这种情况让主管决定看要不要修
作者: ura1210 (jack) 2022-08-26 15:10:00
先记着吧，或是报QA，很有可能不是聊天室本身的问题
作者:
guest0710 (guest0710)
2022-08-26 16:02:00定义哪些问题需要处理 + 做处理机制 然后定期回顾
作者:
bnd0327 (阿噗噗)
2022-08-26 17:46:00如果是你自己做的其实可以先推测是哪一段出问题然后在那一段动手脚看能不能增加重现机率
作者:
single4565 (leekdumpling韭菜水饺)
2022-08-26 18:25:00建议是先纪录给QA，让QA后续追踪
作者: k798976869 (kk) 2022-08-26 19:06:00
不重要 根本不用理
作者:
kirin021 (kirin)
2022-08-26 19:19:00感觉就是websocket一时断掉，重整后重连回来
作者:
EKman (攻略)
2022-08-26 19:24:00等新人来当作他的试用期考核题目
作者:
iamshiao (CircleHsiao)
2022-08-26 20:16:00没头绪就呈报，看主管要不要追。 其实工作久了就会对成本比较有意识，不会像刚出来做那么纠结在个别的问题
作者:
LoveMoon (我不是魔兽三国作者.....)
2022-08-26 20:22:00有使用者上 issue 再说…
作者:
peter98 (新兵)
2022-08-26 22:20:00个人觉得不重要 除非你没其他事情做
在bug tracking system上写unable to reproduce然后切掉
这种大部分是埋log~不过感觉很可能不是聊天室的问题+1
作者:
diabolica (打回大師å†æ”¹ID)
2022-08-27 00:04:00没差
作者: saqwedcxz (阿慶è€å“¥) 2022-08-27 01:38:00
两年来只被发现一次的bug然后还无法重现，正常都放著吧
作者:
qss05 (minami)
2022-08-27 08:09:00就算User反应，但照他的方式没办法重现，而且只有一次的话，通常都会说再观察吧，毕竟你做不出异常也没办法处理
作者:
hduek153 (专业打酱油)
2022-08-27 09:39:00实务上这种传说bug如果没有头绪就是包一包观察吧
作者:
Csir (张胖胖)
2022-08-27 09:46:00有可能是封包掉吗
作者:
DrTech (竹科管理处网军研发人员)
2022-08-27 10:09:00封包掉，正常写都很容易拦截到exception，原文不知道怎么做的。
作者:
GoalBased (Artificail Intelligence)
2022-08-27 15:23:00具体情况具体分析，你的话我觉得找个熟聊天室功能的人看一下你的code就能抓到
作者:
overhead (overhead)
2022-08-28 07:21:00看关键程度和人力成本，决定是否维修。很关键的应用，派出最强老鸟修几个月。相反的，不理它。
作者: lchcoding 2022-08-28 11:27:00
如果我做为你的客户方我应该会加一个测试案例如下1.请找一台桌上型电脑，RJ45网络线为唯一对外通道（若有无线网络，请都先关闭）,开启浏览器，此时要能正常浏览任一你熟悉的网页.拔掉RJ45,此时再refresh浏览网页时，应该报错,无法浏览网页.2.重新接回RJ45,进入聊天室，找朋友聊天，此时讯息-收/发应该都要正常.3.拔掉RJ45, 此时讯息应该发不出去，也收不进来（请用其他讯息工具确认）4.重新接回RJ45,等侯1分钟，聊天室应该在已收/发讯息无损失的情况下，恢复讯息收/发正常.5.［系统强健性测试］.结束虽然这是强制性断线，但应该也能cover你遇到的状况如果你很有实验精神，走进机房，随便找一台路由或 Hub,然后挑一条网络线拔掉再插回去.那么刚刚已经经过这一条网络线建立连线的Client,server 两端遇到的现象就会跟你有九成像了只要中间转接的硬件足够多，server 会以为连线还正常，照常转发讯息，但讯息永远到不了client 端.client端会以为连线还正常不会产生已断线的error
作者:
jej (晃奶大馬桶)
2022-08-28 13:04:00看你的聊天室用什么协定阿这关乎到补救方式 不然你要别人通灵吗还有讯息的发出 都要有log阿 这不是基本的吗？就算ap没做 也会有bright要作看你的内文看不出来要从何debug起
作者: abraxas (Abr.) 2022-08-28 14:57:00
重要度太低完全排不进时程
作者: f750502 (愤宅) 2022-08-30 18:15:00
写压测程式跑看看，如果有发生过跑一下就可以收log了吧
作者:
abola921 (南港金城武)
2022-09-12 23:31:001. 开issue记录发生了什么事。2. 等有空或是再次发生3. 想办法复现bug。4. 动手除错 or 忘了他
作者:
why3042 (yy)
2022-08-26 21:27:00买乖乖
作者:
DrTech (竹科管理处网军研发人员)
2022-08-26 21:27:00没正常的Log可分析？正常有做exception与log处理，没收到讯息会查到怎么复现。
作者:
alihue (wanda wanda)
2022-08-26 21:38:00当然是想办法 reproducing。当然基本功的程式要写好，error handling 做足。此外讯息要做成验证机制，对方可收到才算完整传送（看讯息如何设计）。
作者:
testPtt (测试)
2022-08-26 22:12:00通常是没验证有没有传成功
作者: hobnob (hobnob) 2022-08-26 22:16:00
如果无法重现但不影响软件功能，就加log跟try catch补强程式就够了
作者:
qwe70302 (为何一到90分就会输)
2022-08-26 22:25:00没有error的UIUX bug也只能想办法重现，或是猜猜看code哪一段有可能造成这个问题(简称通灵)
没办法reproduce 就只能想办法让下次发生时能记录到
作者:
DrTech (竹科管理处网军研发人员)
2022-08-26 22:37:00Log 的输出，Debug 的输出可以写在console ，上线后，建议
作者:
giacch 2022-08-26 22:41:00你就让聊天室 每分钟重新整理一次 不就解决了?
看bug严重性与修正的成本，每个bug当然也有它的权重若客户没发现就留个纪录或报告主管有这种情况让主管决定看要不要修
作者: ura1210 (jack) 2022-08-26 23:10:00
先记着吧，或是报QA，很有可能不是聊天室本身的问题
作者:
guest0710 (guest0710)
2022-08-27 00:02:00定义哪些问题需要处理 + 做处理机制 然后定期回顾
作者:
bnd0327 (阿噗噗)
2022-08-27 01:46:00如果是你自己做的其实可以先推测是哪一段出问题然后在那一段动手脚看能不能增加重现机率
作者:
single4565 (leekdumpling韭菜水饺)
2022-08-27 02:25:00建议是先纪录给QA，让QA后续追踪
作者: k798976869 (kk) 2022-08-27 03:06:00
不重要 根本不用理
作者:
kirin021 (kirin)
2022-08-27 03:19:00感觉就是websocket一时断掉，重整后重连回来
作者:
EKman (攻略)
2022-08-27 03:24:00等新人来当作他的试用期考核题目
作者:
iamshiao (CircleHsiao)
2022-08-27 04:16:00没头绪就呈报，看主管要不要追。 其实工作久了就会对成本比较有意识，不会像刚出来做那么纠结在个别的问题
作者:
LoveMoon (我不是魔兽三国作者.....)
2022-08-27 04:22:00有使用者上 issue 再说…
作者:
peter98 (新兵)
2022-08-27 06:20:00个人觉得不重要 除非你没其他事情做
在bug tracking system上写unable to reproduce然后切掉
这种大部分是埋log~不过感觉很可能不是聊天室的问题+1
作者:
diabolica (打回大師å†æ”¹ID)
2022-08-27 08:04:00没差
作者: saqwedcxz (阿慶è€å“¥) 2022-08-27 09:38:00
两年来只被发现一次的bug然后还无法重现，正常都放著吧
作者:
qss05 (minami)
2022-08-27 16:09:00就算User反应，但照他的方式没办法重现，而且只有一次的话，通常都会说再观察吧，毕竟你做不出异常也没办法处理
作者:
hduek153 (专业打酱油)
2022-08-27 17:39:00实务上这种传说bug如果没有头绪就是包一包观察吧
作者:
Csir (张胖胖)
2022-08-27 17:46:00有可能是封包掉吗
作者:
DrTech (竹科管理处网军研发人员)
2022-08-27 18:09:00封包掉，正常写都很容易拦截到exception，原文不知道怎么做的。
作者:
GoalBased (Artificail Intelligence)
2022-08-27 23:23:00具体情况具体分析，你的话我觉得找个熟聊天室功能的人看一下你的code就能抓到
作者:
overhead (overhead)
2022-08-28 15:21:00看关键程度和人力成本，决定是否维修。很关键的应用，派出最强老鸟修几个月。相反的，不理它。
作者: lchcoding 2022-08-28 19:27:00
如果我做为你的客户方我应该会加一个测试案例如下1.请找一台桌上型电脑，RJ45网络线为唯一对外通道（若有无线网络，请都先关闭）,开启浏览器，此时要能正常浏览任一你熟悉的网页.拔掉RJ45,此时再refresh浏览网页时，应该报错,无法浏览网页.2.重新接回RJ45,进入聊天室，找朋友聊天，此时讯息-收/发应该都要正常.3.拔掉RJ45, 此时讯息应该发不出去，也收不进来（请用其他讯息工具确认）4.重新接回RJ45,等侯1分钟，聊天室应该在已收/发讯息无损失的情况下，恢复讯息收/发正常.5.［系统强健性测试］.结束虽然这是强制性断线，但应该也能cover你遇到的状况如果你很有实验精神，走进机房，随便找一台路由或 Hub,然后挑一条网络线拔掉再插回去.那么刚刚已经经过这一条网络线建立连线的Client,server 两端遇到的现象就会跟你有九成像了只要中间转接的硬件足够多，server 会以为连线还正常，照常转发讯息，但讯息永远到不了client 端.client端会以为连线还正常不会产生已断线的error
作者:
jej (晃奶大馬桶)
2022-08-28 21:04:00看你的聊天室用什么协定阿这关乎到补救方式 不然你要别人通灵吗还有讯息的发出 都要有log阿 这不是基本的吗？就算ap没做 也会有bright要作看你的内文看不出来要从何debug起
作者: abraxas (Abr.) 2022-08-28 22:57:00
重要度太低完全排不进时程
作者: f750502 (愤宅) 2022-08-31 02:15:00
写压测程式跑看看，如果有发生过跑一下就可以收log了吧
作者:
abola921 (南港金城武)
2022-09-13 07:31:001. 开issue记录发生了什么事。2. 等有空或是再次发生3. 想办法复现bug。4. 动手除错 or 忘了他