程序发现了一个程序里未来可能会触发的 bug。 是当时摸摸修掉，别人没有感知呢。 还是等 bug 发作了，去修复它，让别人觉得解决了一个重大的问题。

[3dwelcome]

如果是自己写的 BUG，肯定越早修复越好，你并不确定，会不会因为这个 BUG，引发其他关联小问题。
我觉得吧，衡量一个码农的价值，是看他写的代码有多少人在实际使用。而不是公司里那个最会修 BUG 的人。

[manami]

别动。我也有过类似经历，不公开的 bug 你乱动修最后出问题是要背锅的

[3dwelcome]

@manami 你可真是机灵鬼。

[dji38838c]

可以选的另一个态度是：根本不在意。
无须在意别人怎么看，你想怎么做就做好了，不必最终目的是"让别人觉得如何"

[imdong]

对于这种问题当然是早发现早治疗，免得贻误时机。

我相反，有另一个问题：

发现一个理论上永远无法触发但明确是有 BUG 的代码，要不要修复？

[liuzhaowei55]

千万别动，你以为只是这一个 bug，其实后边还有 n 多依赖此 bug 而写的特性，所以千万别动。

[txdy1]

@imdong 把这段逻辑删掉

[wangbenjun5]

能问出这种问题的人还是年轻，除非以前那段代码是你自己写的，不然永远不要在未和别人沟通过的情况下擅自修改别人代码。。。

[ebony0319]

在你不能完全控制的情况下别动。我之前改过一个，用 get 方法用一堆 id 去查。我发现在 id 过长情况下会 get 方法会报错。于是将请求分为 100 个每组分配查询。当时以为很简单，结果鸡儿里面还有一个排序。第二个就是有一个查询条件，方向他边界没有处理好。给他加了一句。结果字段写错了。后面就悲剧了。

[php8]

有些 bug 活久了就成精变 feature 了，可能有的代码依赖这个 bug 一改就翻车。我亲身经历过这种 bug，改就是作死，偷偷改就是花样作死。

[ujued]

改，依价值观行事

[lihongming]

@php8 所以屎山也是山，只要够古老，就会有神仙

[Stictonotus]

是自己写的趁早改 不是的话 如果你不能完全理解代码的逻辑那就别动 有的你看上去是 bug 但是人家是个 feature 。。

[renmu123]

你写的就直接改，不是的话就提给产品经理，改不改随他咯

[lscho]

@imdong 理论上永远无法触发，那理论上就不是 bug，修他干啥？修了有钱吗？有钱就修

[zpxshl]

负负得正的事情我遇到好几次了。
修了个 bug，引出另一个 bug，后者还更严重...

[akakidz]

提给老大来决定改不改...

[1423]

考虑一下权利和义务对等原则

[msg7086]

如果你和老大关系好，就和他提一下然后开个 ticket 放着。

[BUappend]

@manami 是的，我就背过锅

[akring]

上报上级，如果是自己写的，还要同步到测试并建立 Issue Ticket，然后看版本迭代计划安排修复和回归。

无论是自己私自改还是假装不知道，都要冒着定时炸弹爆炸之后紧急救火的风险，对自己和对团队都不负责任。更何况 Git 记录在那摆着，谁写的 Bug，谁悄悄改了东西没同步测试回归最终引发了其他事故，一目了然，逃避一点都没有用。

[xcstream]

想表达的是扁鹊的问题
扁鹊：长兄最好，中兄次之，我最差。
有些事情有益但没成果

[mingl0280]

上报啊，发现 bug，ticket 有记录以后大家都知道了。

[darksword21]

不是自己写的还是别乱动吧，说不定是 feature 不是 bug，改了出了问题一顿喷你到时候感觉像吃了屎

[jonathanchoo]

刚毕业那会我会偷偷改掉
可现在
当没看见

[Tink]

自己的 bug 不改等着过年？别人的 bug 告诉他就行了，你别动

[saberlong]

直接提 bug 。
接下来会安排到某个迭代由某个人解决。
改的人会分析影响范围。
改完也有回归测试。

[codyfeng]

开一个 ticket 描述一下这个 bug，让领导决定如何处理

[gggxxxx]

立即提出来，但是不要去修改。等大家 review 了后再改是比较稳妥的做法。任何上线了或者已经进入一定阶段的程序，动任何一行代码都牵扯到需要堆人力物力去测试。偷偷修改等于是将当前测试作废。

没有做充分测试的代码不要去凭想象断言其代码有问题，除非自己有明确的测试结果。万一自己想的狭义了就尴尬了。

还有一些代码看上去是有明确 bug 的，但是不太影响使用。我以前工作中遇到过这种情况，我们告诉客户代码发现有 bug，客户直接说别动代码！你们说的那个 bug 我们知道，我们每天重启一次机器就避免了........

[ericls]

马上公开透明沟通这个问题

[Leonard]

如果自己写的就改，别人写的先不要乱动。。

[moonrailgun]

我就好奇没有 code review 的么。怎么做到偷偷改代码的

[clayyj1210]

赞同#21 的做法报告上去。不过即使有 Git 记录，有些人也未必看哦。

[NexTooo]

看规模吧。也可以考虑上报先。
不太建议私自改动，我前阵子改了一句看似没啥用的代码，然后发现在某些情况下出问题了（ 才知道这是同事特意这么写的
不问过同事写这句的缘由和依赖这一段代码的地方，随意乱动可能反而真出 bug 了

[young1lin]

不要乱动别人的代码，万一出了更多的 bug，哭都来不及。自己写的，并且了然于胸的，马上改了。代码只有不断重构才能 bug 变少。

[linxl]

就怕是多米诺骨牌

[kanemochi]

你以为这是一个 bug，建议你看下提交时间，八成是凌晨两三点提交的，福报状态下的产物，很多核心逻辑依赖这个 bug，你不改又不是不能用，你改了出故障你一定凉。

[vincent7245]

站在打工人的角度：不管。
只要动了你就要对后果负责，鬼知道修复这个 bug 会引起什么新的 bug 。
其次，某天 bug 爆发，跟我有什么关系，公司又不是我的，我只是个打工的。

[dany813]

不能直接改，可以上报定位下，是否有改动的价值

[Kili9]

你以为改好了这个 bug，但你很难发现会不会引发另外依赖性的 bug，如果依赖性太强或者不知道牵扯到其他服务功能的最好跟上级汇报，制定方案，安排产品排期，改完让测试过一遍

[timedivision]

自己写的就改，别人写的不改，但是可以跟别人说

[hijoker]

@lihongming 大哥,你真是人才

[dorothyREN]

@imdong #5 理论上 有驾照的人都会开车，理论上开车的人都有驾照。那么问题来了。。。

[dnsaq]

职业素养问题，作为打工人我觉得可以不改但是得有个度。第一可以不改，但不要给他人带来麻烦，不改出问题让运维背锅？？？第二可以不改但一定要做记录，或者提前想好应对方案便于真出问题的时候及时处理。

[opengps]

发现 bug 得提出，未必需要你来修复。
修复这个 bug 并没有被安排成你的任务，如果你的 deadline 时间宽裕，那可以好心去做，然而 deadline 里并没有包含这个 bug 修复工作，你没必要承担因此带来的风险。

[fenglangjuxu]

@zpxshl 我也是 还基本都是修改一行代码导致的

[xsqfjys]

提出来走个 bug 修复流程呗，有 bug 多正常啊。但是随便改代码没有测试知道没有业务知道万一出了问题就尴尬了

[lakehylia]

不管是自己的 bug 还是别人的 bug，只要上线了，那就报上去决定修不修。修 bug 是要检查相关业务的，所有涉及到的业务线都要做一次回归测试的。

[vanityfairn]

永远不要在未和别人沟通过的情况，偷偷摸摸 fix，这简直是花样作死，抓到本季度我这儿 kpi 为 0 。可以作为正常得报 bug，然后走 bug 上线流程。同时界定好责任人

[vagranth]

自己给自己发一个 bug 然后改掉呗

[soulmt]

正常流程： 上报风险， 不要夹带私货，做好了没人奖励你，做不好锅就是你的
心机一点： 搞清楚 bug 的原因，坐等发作，然后 bug 出来之后像模像样的用最快的速度搞定，可以赚一波 kpi

[jkhere]

@imdong 如果一个 bug 永远无法触发的话那就不算 bug 吧

[FaiChou]

放奇葩说上 让他们辩论下吧.

[gongshishao126]

@ebony0319 只有经历过的人才懂，get 请求由于拼接参数在 url 上，默认长度有限好像是 2k 。参数长度无法估量的最好是改用 post 请求

[hikari2]

华佗有两个兄弟，你觉得谁医术最高超？

[qoras]

自己的 bug，确认改动无影响，偷偷修掉
同组在职同事的 bug，告诉相应的同事这件事
同级离职同事的 bug，告知领导，不然你修了做了好事领导不知道，万一出事了还要背锅
其它组的人的 bug，看心情吧，怎样都行，毕竟现在大部分公司都不尊重程序员的价值

[jsjgjbzhang]

找个关键时刻 加班解决

[passerbytiny]

第一，任何时候都不要偷偷改东西，你改了啥，在提交信息上至少要点一下。第二，在没有保障措施——测试或评审——的情况下，绝对不要改代码。第三，如果没有 QA，或者 QA 只是个摆设，或者 QA 不管过程，或者 QA 只是个测试，那你干什么都行。

[nomemo]

报出来，改不改再说。

[jiumingzhu]

离职同事写的代码,未上线.接手项目后发现有 bug,权衡了方法的复杂度和 debug 耗时后,我直接重写了那个方法 233

[fumeboy]

善战者无赫赫之功

[GX88624]

别动只要不是严重的 bug,当他不存在.严重的先报告,不过你报告了,这估计要你处理了.

[securityCoding]

静下来梳理下 bug 影响范围 , 让领导和团队都知道这个事情 ,然后排期开始干

[pixiaotiao]

我改过，改出了更大的 bug，还好没人发现。

[flowercoder]

有测试吗环境吗？有的话可以改完试，试完没问题再提交。
没测试环境就别改了。
你们领导懂不懂代码，不懂的话也可以改，懂行的话就别改了，除非发现 bug 再改。

[lidlesseye11]

@xcstream
你的意思领导是昏君了？
发现了一个潜在的 bug 怎么会是没成果。。

[cooker498]

提技术需求

[thetbw]

idea 可以看出哪里调用了这个方法，不过我一般不会改吧，顶多在上面加个 @Deprecated 或者 FIXME

[renzituo]

有些 bug 用户使用时间久了就当成正常的了，你改了反而成了 bug 。 曾经做新业务的时候碰到一个老逻辑的「 bug 」，明明未读却要往已读的逻辑里跑，顺手改完后，还测试了，结果好家伙，整站 N 多投诉 ，说一下子出现好多未读数，我花了一天时间跟各个领导解释 为什么这个不能算 P1 bug

[akring]

@renzituo #68 大哥你们改完 Bug 不过测试的咩？

[akring]

@renzituo #68 Sorry 没看仔细，这种过了测试还出问题的感觉就得一人一半责任了

[James369]

我想贴一幅经典的动图，就是有一只小熊在修理水管。。 怎么贴

[tankren]

要看上线了多久吧 遇事不决找领导

[julyclyde]

首先：肯定不要偷偷摸摸修复
其次，是否大张旗鼓，这个看企业文化来定
但至少要有关于这个事来龙去脉的整套追踪