程序发现了一个程序里未来可能会触发的 bug。 是当时摸摸修掉，别人没有感知呢。 还是等 bug 发作了，去修复它，让别人觉得解决了一个重大的问题。
xcstream · 2021-01-03 21:28:22 +08:00 · 9747 次点击这是一个创建于 1439 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
3dwelcome 2021-01-03 21:33:01 +08:00  1
如果是自己写的 BUG，肯定越早修复越好，你并不确定，会不会因为这个 BUG，引发其他关联小问题。
我觉得吧，衡量一个码农的价值，是看他写的代码有多少人在实际使用。而不是公司里那个最会修 BUG 的人。 |
 |
2
manami 2021-01-03 21:35:01 +08:00 via Android 8
别动。我也有过类似经历，不公开的 bug 你乱动修最后出问题是要背锅的
|
 |
4
dji38838c 2021-01-03 21:38:46 +08:00 1
可以选的另一个态度是：根本不在意。
无须在意别人怎么看，你想怎么做就做好了，不必最终目的是"让别人觉得如何" |
 |
5
imdong 2021-01-03 21:38:47 +08:00
对于这种问题当然是早发现早治疗，免得贻误时机。
我相反，有另一个问题： 发现一个理论上永远无法触发但明确是有 BUG 的代码，要不要修复？ |
 |
6
liuzhaowei55 2021-01-03 21:38:59 +08:00 via Android 4
千万别动，你以为只是这一个 bug，其实后边还有 n 多依赖此 bug 而写的特性，所以千万别动。
|
 |
8
wangbenjun5 2021-01-03 22:10:21 +08:00
能问出这种问题的人还是年轻，除非以前那段代码是你自己写的，不然永远不要在未和别人沟通过的情况下擅自修改别人代码。。。
|
 |
9
ebony0319 2021-01-03 22:15:43 +08:00 via Android 1
在你不能完全控制的情况下别动。我之前改过一个，用 get 方法用一堆 id 去查。我发现在 id 过长情况下会 get 方法会报错。于是将请求分为 100 个每组分配查询。当时以为很简单，结果鸡儿里面还有一个排序。第二个就是有一个查询条件，方向他边界没有处理好。给他加了一句。结果字段写错了。后面就悲剧了。
|
 |
10
php8 2021-01-03 22:30:25 +08:00 via Android 13
有些 bug 活久了就成精变 feature 了，可能有的代码依赖这个 bug 一改就翻车。我亲身经历过这种 bug，改就是作死，偷偷改就是花样作死。
|
 |
11
ujued 2021-01-03 22:42:06 +08:00 via iPhone
改，依价值观行事
|
 |
12
lihongming 2021-01-03 22:50:26 +08:00 via iPhone 18
@php8 所以屎山也是山，只要够古老，就会有神仙
|
 |
13
Stictonotus 2021-01-03 22:57:45 +08:00 via Android
是自己写的趁早改 不是的话 如果你不能完全理解代码的逻辑那就别动 有的你看上去是 bug 但是人家是个 feature 。。
|
 |
14
renmu123 2021-01-03 23:03:31 +08:00 via Android
你写的就直接改，不是的话就提给产品经理，改不改随他咯
|
 |
16
zpxshl 2021-01-03 23:07:56 +08:00 via Android
负负得正的事情我遇到好几次了。
修了个 bug，引出另一个 bug，后者还更严重... |
 |
17
akakidz 2021-01-04 01:03:53 +08:00 via Android
提给老大来决定改不改...
|
 |
18
1423 2021-01-04 01:19:44 +08:00 via iPhone
考虑一下权利和义务对等原则
|
 |
19
msg7086 2021-01-04 01:20:55 +08:00 via Android
如果你和老大关系好，就和他提一下然后开个 ticket 放着。
|
 |
21
akring 2021-01-04 01:37:44 +08:00 3
上报上级，如果是自己写的，还要同步到测试并建立 Issue Ticket，然后看版本迭代计划安排修复和回归。
无论是自己私自改还是假装不知道，都要冒着定时炸弹爆炸之后紧急救火的风险，对自己和对团队都不负责任。更何况 Git 记录在那摆着，谁写的 Bug，谁悄悄改了东西没同步测试回归最终引发了其他事故，一目了然，逃避一点都没有用。 |
 |
22
xcstream OP 想表达的是扁鹊的问题
扁鹊：长兄最好，中兄次之，我最差。 有些事情有益但没成果 |
 |
23
mingl0280 2021-01-04 02:58:28 +08:00
上报啊，发现 bug，ticket 有记录以后大家都知道了。
|
 |
24
darksword21 2021-01-04 07:54:38 +08:00 via iPhone
不是自己写的还是别乱动吧，说不定是 feature 不是 bug，改了出了问题一顿喷你到时候感觉像吃了屎
|
 |
25
jonathanchoo 2021-01-04 08:29:10 +08:00 via iPhone
刚毕业那会我会偷偷改掉
可现在 当没看见 |
 |
26
Tink 2021-01-04 08:32:30 +08:00 via Android
自己的 bug 不改等着过年？别人的 bug 告诉他就行了，你别动
|
 |
27
saberlong 2021-01-04 08:36:50 +08:00 via Android
直接提 bug 。
接下来会安排到某个迭代由某个人解决。 改的人会分析影响范围。 改完也有回归测试。 |
 |
28
codyfeng 2021-01-04 08:58:10 +08:00 via Android
开一个 ticket 描述一下这个 bug，让领导决定如何处理
|
 |
29
gggxxxx 2021-01-04 08:58:20 +08:00
立即提出来，但是不要去修改。等大家 review 了后再改是比较稳妥的做法。任何上线了或者已经进入一定阶段的程序，动任何一行代码都牵扯到需要堆人力物力去测试。偷偷修改等于是将当前测试作废。
没有做充分测试的代码不要去凭想象断言其代码有问题，除非自己有明确的测试结果。万一自己想的狭义了就尴尬了。 还有一些代码看上去是有明确 bug 的，但是不太影响使用。我以前工作中遇到过这种情况，我们告诉客户代码发现有 bug，客户直接说别动代码！你们说的那个 bug 我们知道，我们每天重启一次机器就避免了........ |
 |
30
ericls 2021-01-04 09:13:47 +08:00
马上公开透明沟通这个问题
|
 |
31
Leonard 2021-01-04 09:16:46 +08:00
如果自己写的就改，别人写的先不要乱动。。
|
 |
32
moonrailgun 2021-01-04 09:18:50 +08:00
我就好奇没有 code review 的么。怎么做到偷偷改代码的
|
 |
33
clayyj1210 2021-01-04 09:36:01 +08:00
赞同#21 的做法报告上去。不过即使有 Git 记录，有些人也未必看哦。
|
 |
34
NexTooo 2021-01-04 09:36:34 +08:00
看规模吧。也可以考虑上报先。
不太建议私自改动，我前阵子改了一句看似没啥用的代码，然后发现在某些情况下出问题了（ 才知道这是同事特意这么写的 不问过同事写这句的缘由和依赖这一段代码的地方，随意乱动可能反而真出 bug 了 |
 |
35
young1lin 2021-01-04 09:38:56 +08:00
不要乱动别人的代码，万一出了更多的 bug，哭都来不及。自己写的，并且了然于胸的，马上改了。代码只有不断重构才能 bug 变少。
|
 |
36
linxl 2021-01-04 10:15:02 +08:00
就怕是多米诺骨牌
|
 |
37
kanemochi 2021-01-04 10:18:36 +08:00
你以为这是一个 bug，建议你看下提交时间，八成是凌晨两三点提交的，福报状态下的产物，很多核心逻辑依赖这个 bug，你不改又不是不能用，你改了出故障你一定凉。
|
 |
38
vincent7245 2021-01-04 10:21:13 +08:00 1
站在打工人的角度：不管。
只要动了你就要对后果负责，鬼知道修复这个 bug 会引起什么新的 bug 。 其次，某天 bug 爆发，跟我有什么关系，公司又不是我的，我只是个打工的。 |
 |
39
dany813 2021-01-04 10:24:18 +08:00
不能直接改，可以上报定位下，是否有改动的价值
|
 |
40
Kili9 2021-01-04 11:11:31 +08:00
你以为改好了这个 bug，但你很难发现会不会引发另外依赖性的 bug，如果依赖性太强或者不知道牵扯到其他服务功能的最好跟上级汇报，制定方案，安排产品排期，改完让测试过一遍
|
 |
41
timedivision 2021-01-04 11:18:34 +08:00
自己写的就改，别人写的不改，但是可以跟别人说
|
 |
42
hijoker 2021-01-04 11:37:54 +08:00
@lihongming 大哥,你真是人才
|
 |
43
dorothyREN 2021-01-04 11:51:31 +08:00
@imdong #5 理论上 有驾照的人都会开车，理论上开车的人都有驾照。那么问题来了。。。
|
 |
44
dnsaq 2021-01-04 12:47:16 +08:00 via iPhone
职业素养问题，作为打工人我觉得可以不改但是得有个度。第一可以不改，但不要给他人带来麻烦，不改出问题让运维背锅？？？第二可以不改但一定要做记录，或者提前想好应对方案便于真出问题的时候及时处理。
|
 |
45
opengps 2021-01-04 12:52:49 +08:00
发现 bug 得提出，未必需要你来修复。
修复这个 bug 并没有被安排成你的任务，如果你的 deadline 时间宽裕，那可以好心去做，然而 deadline 里并没有包含这个 bug 修复工作，你没必要承担因此带来的风险。 |
 |
46
fenglangjuxu 2021-01-04 13:32:40 +08:00 via iPhone
@zpxshl 我也是 还基本都是修改一行代码导致的
|
 |
47
xsqfjys 2021-01-04 13:37:08 +08:00
提出来走个 bug 修复流程呗，有 bug 多正常啊。但是随便改代码没有测试知道没有业务知道万一出了问题就尴尬了
|
 |
48
lakehylia 2021-01-04 13:51:26 +08:00
不管是自己的 bug 还是别人的 bug，只要上线了，那就报上去决定修不修。修 bug 是要检查相关业务的，所有涉及到的业务线都要做一次回归测试的。
|
 |
49
vanityfairn 2021-01-04 14:16:32 +08:00
永远不要在未和别人沟通过的情况，偷偷摸摸 fix，这简直是花样作死，抓到本季度我这儿 kpi 为 0 。可以作为正常得报 bug，然后走 bug 上线流程。同时界定好责任人
|
 |
50
vagranth 2021-01-04 14:31:31 +08:00
自己给自己发一个 bug 然后改掉呗
|
 |
51
soulmt 2021-01-04 14:34:55 +08:00
正常流程： 上报风险， 不要夹带私货，做好了没人奖励你，做不好锅就是你的
心机一点： 搞清楚 bug 的原因，坐等发作，然后 bug 出来之后像模像样的用最快的速度搞定，可以赚一波 kpi |
 |
53
FaiChou 2021-01-04 15:48:09 +08:00
放奇葩说上 让他们辩论下吧.
|
 |
54
gongshishao126 2021-01-04 15:58:27 +08:00
@ebony0319 只有经历过的人才懂，get 请求由于拼接参数在 url 上，默认长度有限好像是 2k 。参数长度无法估量的最好是改用 post 请求
|
 |
55
hikari2 2021-01-04 16:08:39 +08:00
华佗有两个兄弟，你觉得谁医术最高超？
|
 |
56
qoras 2021-01-04 16:09:10 +08:00
自己的 bug，确认改动无影响，偷偷修掉
同组在职同事的 bug，告诉相应的同事这件事 同级离职同事的 bug，告知领导，不然你修了做了好事领导不知道，万一出事了还要背锅 其它组的人的 bug，看心情吧，怎样都行，毕竟现在大部分公司都不尊重程序员的价值 |
 |
57
jsjgjbzhang 2021-01-04 16:39:08 +08:00
找个关键时刻 加班解决
|
 |
58
passerbytiny 2021-01-04 16:58:08 +08:00 via Android
第一，任何时候都不要偷偷改东西，你改了啥，在提交信息上至少要点一下。第二，在没有保障措施——测试或评审——的情况下，绝对不要改代码。第三，如果没有 QA，或者 QA 只是个摆设，或者 QA 不管过程，或者 QA 只是个测试，那你干什么都行。
|
 |
59
nomemo 2021-01-04 17:33:53 +08:00
报出来，改不改再说。
|
 |
60
jiumingzhu 2021-01-04 17:53:50 +08:00
离职同事写的代码,未上线.接手项目后发现有 bug,权衡了方法的复杂度和 debug 耗时后,我直接重写了那个方法 233
|
 |
61
fumeboy 2021-01-04 17:56:12 +08:00
善战者无赫赫之功
|
 |
62
GX88624 2021-01-04 17:59:23 +08:00
别动只要不是严重的 bug,当他不存在.严重的先报告,不过你报告了,这估计要你处理了.
|
 |
63
securityCoding 2021-01-04 18:06:47 +08:00
静下来梳理下 bug 影响范围 , 让领导和团队都知道这个事情 ,然后排期开始干
|
 |
64
pixiaotiao 2021-01-04 18:47:27 +08:00 via Android
我改过，改出了更大的 bug，还好没人发现。
|
 |
65
flowercoder 2021-01-04 20:08:47 +08:00
有测试吗环境吗？有的话可以改完试，试完没问题再提交。
没测试环境就别改了。 你们领导懂不懂代码，不懂的话也可以改，懂行的话就别改了，除非发现 bug 再改。 |
 |
66
lidlesseye11 2021-01-04 20:40:42 +08:00
|
 |
67
cooker498 2021-01-04 21:51:28 +08:00
提技术需求
|
 |
68
thetbw 2021-01-04 22:42:23 +08:00 via Android
idea 可以看出哪里调用了这个方法，不过我一般不会改吧，顶多在上面加个 @Deprecated 或者 FIXME
|
 |
69
renzituo 2021-01-04 22:50:35 +08:00
有些 bug 用户使用时间久了就当成正常的了，你改了反而成了 bug 。 曾经做新业务的时候碰到一个老逻辑的「 bug 」，明明未读却要往已读的逻辑里跑，顺手改完后，还测试了，结果好家伙，整站 N 多投诉 ，说一下子出现好多未读数，我花了一天时间跟各个领导解释 为什么这个不能算 P1 bug
|
 |
72
James369 2021-01-05 10:04:04 +08:00 1
我想贴一幅经典的动图，就是有一只小熊在修理水管。。 怎么贴
|
 |
73
tankren 2021-01-05 13:42:51 +08:00
要看上线了多久吧 遇事不决找领导
|
 |
74
julyclyde 2021-01-06 16:42:23 +08:00
首先：肯定不要偷偷摸摸修复
其次，是否大张旗鼓，这个看企业文化来定 但至少要有关于这个事来龙去脉的整套追踪 |
Select Language