作者banana2014 (香蕉共和国)
看板Soft_Job
标题[请益] 业界遇到这种bug该怎麽处理?
时间Fri Aug 26 13:24:20 2022
我大概在两年前左右做了一个网页版的聊天室
约莫上个月的时候，我无意间发现了一个bug
那个bug是对方已经传了一个新讯息给我，但我这边却完全没收到他传给我的新讯息
但等我重新整理聊天室页面之後，那个bug就从此彻底销声匿迹了
而且从两年前到bug发生当时的那段时间以及bug发生当时至今这段时间，用起来都很正常
也就是说那个bug只在上个月那一次发生之後就再也没被我看到了
虽然我不是IT业界的专业程式设计师
不过我想问一下：
当遇到这种程式已写了两年以上才难得出现过一次算是有点严重的bug被你发现到了
通常专业的都怎麽处理?
因为这样的bug或许很难刻意的被制造出来，所以几乎只能靠运气碰碰看了
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.226.110.67 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1661491462.A.11E.html
1F：推 why3042: 买乖乖 08/26 13:27
2F：→ DrTech: 没正常的Log可分析？ 08/26 13:27
其实我当时在发现该bug时没有开console分析
等我发现并看到该bug时已经来不及了
console没有记录到
有个难处是，我不可能每次用这个聊天室时，都要特别坐到电脑桌前，打开电脑开console去看吧
有时候可能只是用个手机随便进一下聊天室用用看
结果那个bug就「无意间」跑出来的
※ 编辑: banana2014 (36.226.110.67 台湾), 08/26/2022 13:31:51
3F：→ DrTech: 正常有做exception与log处理，没收到讯息会查到怎麽复现。 08/26 13:29
对了，其实并不是每个bug都是以error的形式出来的
只要结果和画面是不符合期待的，应该都被归类作bug
所以即使程式有写try...catch
bug的出现也不一定会跳出error log让你知道
这也是我觉得处理起来最棘手的bug之一
因为它根本连错误讯息都不会跳出来让你知道
※ 编辑: banana2014 (36.226.110.67 台湾), 08/26/2022 13:35:06
※ 编辑: banana2014 (36.226.110.67 台湾), 08/26/2022 13:39:40
4F：→ alihue: 当然是想办法 reproducing。当然基本功的程式要写好，err 08/26 13:38
5F：→ alihue: or handling 做足。此外讯息要做成验证机制，对方可收到 08/26 13:38
6F：→ alihue: 才算完整传送（看讯息如何设计）。 08/26 13:38
7F：推 abccbaandy: 就不理阿...无法重现的bug没有修的必要XD 08/26 14:04
8F：→ testPtt: 通常是没验证有没有传成功 08/26 14:12
9F：推 hobnob: 如果无法重现但不影响软体功能，就加log跟try catch补强程 08/26 14:16
10F：→ hobnob: 式就够了 08/26 14:16
11F：推 aaa1234136: 偶发就先记log，看之後有没有办法找出问题 08/26 14:24
12F：推 qwe70302: 没有error的UIUX bug也只能想办法重现，或是猜猜看code 08/26 14:25
13F：→ qwe70302: 哪一段有可能造成这个问题(简称通灵) 08/26 14:25
14F：推 longlyeagle: 没办法reproduce 就只能想办法让下次发生时能记录到 08/26 14:35
15F：→ DrTech: Log 的输出，Debug 的输出可以写在console ，上线後，建议 08/26 14:37
16F：→ longlyeagle: 加log是一种 还有其他能用的都加一加 08/26 14:37
17F：→ DrTech: 上线後是写在file才能追踪。 08/26 14:37
18F：推 giacch: 你就让聊天室 每分钟重新整理一次 不就解决了? 08/26 14:41
19F：推 Lomonosov: sentry 08/26 14:41
20F：推 OriginStar: 看bug严重性与修正的成本，每个bug当然也有它的权重 08/26 15:01
21F：→ OriginStar: 若客户没发现就留个纪录或报告主管有这种情况让主管 08/26 15:02
22F：→ OriginStar: 决定看要不要修 08/26 15:03
23F：嘘 MoonCode: 08/26 15:06
24F：推 ura1210: 先记着吧，或是报QA，很有可能不是聊天室本身的问题 08/26 15:10
25F：推 guest0710: 定义哪些问题需要处理 + 做处理机制 然後定期回顾 08/26 16:02
26F：推 bnd0327: 如果是你自己做的其实可以先推测是哪一段出问题 08/26 17:46
27F：→ bnd0327: 然後在那一段动手脚看能不能增加重现机率 08/26 17:46
28F：推 winnie830925: 怎麽觉得这篇有既视感XDDD 08/26 17:46
29F：推 single4565: 建议是先纪录给QA，让QA後续追踪 08/26 18:25
30F：推 k798976869: 不重要 根本不用理 08/26 19:06
31F：→ kirin021: 感觉就是websocket一时断掉，重整後重连回来 08/26 19:19
32F：推 EKman: 等新人来当作他的试用期考核题目 08/26 19:24
33F：推 arcade0425: 怎麽跟前阵子的 10% 那篇有点像 08/26 20:05
34F：→ iamshiao: 没头绪就呈报，看主管要不要追。 其实工作久了就会对成 08/26 20:16
35F：→ iamshiao: 本比较有意识，不会像刚出来做那麽纠结在个别的问题 08/26 20:16
36F：推 LoveMoon: 有使用者上 issue 再说… 08/26 20:22
37F：→ peter98: 个人觉得不重要 除非你没其他事情做 08/26 22:20
38F：推 kurtsgm: 在bug tracking system上写unable to reproduce然後切掉 08/26 22:53
39F：推 viper9709: 这种大部分是埋log~不过感觉很可能不是聊天室的问题+1 08/26 23:51
40F：→ diabolica: 没差 08/27 00:04
41F：→ saqwedcxz: 两年来只被发现一次的bug然後还无法重现，正常都放着吧 08/27 01:38
42F：→ qss05: 就算User反应，但照他的方式没办法重现，而且只有一次的话 08/27 08:09
43F：→ qss05: ，通常都会说再观察吧，毕竟你做不出异常也没办法处理 08/27 08:09
44F：推 hduek153: 实务上这种传说bug如果没有头绪就是包一包观察吧 08/27 09:39
45F：推 Csir: 有可能是封包掉吗 08/27 09:46
46F：→ DrTech: 封包掉，正常写都很容易拦截到exception，原文不知道怎麽 08/27 10:09
47F：→ DrTech: 做的。 08/27 10:09
48F：推 WaterLengend: 都无法描述跟复现了，顶多记下来下次有发现再说 08/27 11:27
49F：→ GoalBased: 具体情况具体分析，你的话我觉得找个熟聊天室功能的人 08/27 15:23
50F：→ GoalBased: 看一下你的code就能抓到 08/27 15:23
51F：→ ChungLi5566: 你们传讯息没有留文本纪录？至少要留10天吧 08/27 19:02
52F：推 overhead: 看关键程度和人力成本，决定是否维修。很关键的应用， 08/28 07:21
53F：→ overhead: 派出最强老鸟修几个月。相反的，不理它。 08/28 07:21
54F：→ lchcoding: 如果我做为你的客户方 08/28 11:27
55F：→ lchcoding: 我应该会加一个测试案例如下 08/28 11:27
56F：→ lchcoding: 1.请找一台桌上型电脑，RJ45 08/28 11:27
57F：→ lchcoding: 网路线为唯一对外通道 08/28 11:27
58F：→ lchcoding: （若有无线网路，请都先关闭）, 08/28 11:27
59F：→ lchcoding: 开启浏览器，此时要能正常浏览 08/28 11:27
60F：→ lchcoding: 任一你熟悉的网页.拔掉RJ45, 08/28 11:27
61F：→ lchcoding: 此时再refresh浏览网页时， 08/28 11:27
62F：→ lchcoding: 应该报错,无法浏览网页. 08/28 11:27
63F：→ lchcoding: 2.重新接回RJ45,进入聊天室， 08/28 11:27
64F：→ lchcoding: 找朋友聊天，此时讯息-收/发 08/28 11:27
65F：→ lchcoding: 应该都要正常. 08/28 11:27
66F：→ lchcoding: 3.拔掉RJ45, 此时讯息应该 08/28 11:27
67F：→ lchcoding: 发不出去，也收不进来 08/28 11:27
68F：→ lchcoding: （请用其他讯息工具确认） 08/28 11:27
69F：→ lchcoding: 4.重新接回RJ45,等侯1分钟， 08/28 11:27
70F：→ lchcoding: 聊天室应该在已收/发讯息 08/28 11:27
71F：→ lchcoding: 无损失的情况下，恢复讯息收/发正常. 08/28 11:27
72F：→ lchcoding: 5.［系统强健性测试］.结束 08/28 11:27
73F：→ lchcoding: 虽然这是强制性断线， 08/28 11:28
74F：→ lchcoding: 但应该也能cover你遇到的状况 08/28 11:28
75F：→ lchcoding: 如果你很有实验精神， 08/28 11:29
76F：→ lchcoding: 走进机房，随便找一台路由 08/28 11:29
77F：→ lchcoding: 或 Hub,然後挑一条网路线 08/28 11:29
78F：→ lchcoding: 拔掉再插回去.那麽刚刚已经 08/28 11:29
79F：→ lchcoding: 经过这一条网路线建立连线 08/28 11:29
80F：→ lchcoding: 的Client,server 两端遇到的现象 08/28 11:29
81F：→ lchcoding: 就会跟你有九成像了 08/28 11:29
82F：→ lchcoding: 只要中间转接的硬体足够多， 08/28 11:29
83F：→ lchcoding: server 会以为连线还正常， 08/28 11:29
84F：→ lchcoding: 照常转发讯息，但讯息永远 08/28 11:29
85F：→ lchcoding: 到不了client 端. 08/28 11:29
86F：→ lchcoding: client端会以为连线还正常 08/28 11:29
87F：→ lchcoding: 不会产生已断线的error 08/28 11:29
88F：→ jej: 看你的聊天室用什麽协定阿 08/28 13:04
89F：→ jej: 这关乎到补救方式 不然你要别人通灵吗 08/28 13:04
90F：→ jej: 还有讯息的发出 都要有log阿 这不是基本的吗？ 08/28 13:04
91F：→ jej: 就算ap没做 也会有bright要作 08/28 13:04
92F：→ jej: 看你的内文看不出来要从何debug起 08/28 13:04
93F：推 abraxas: 重要度太低完全排不进时程 08/28 14:57
94F：嘘 f750502: 写压测程式跑看看，如果有发生过跑一下就可以收log了吧 08/30 18:15
95F：推 abola921: 1. 开issue记录发生了什麽事。2. 等有空或是再次发生 09/12 23:31
96F：→ abola921: 3. 想办法复现bug。4. 动手除错 or 忘了他 09/12 23:32