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

[xcstream]

[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，如果依赖性太强或者不知道牵扯到其他服务功能的最好跟上级汇报，制定方案，安排产品排期，改完让测试过一遍