程序发现了一个程序里未来可能会触发的 bug。 是当时摸摸修掉，别人没有感知呢。 还是等 bug 发作了，去修复它，让别人觉得解决了一个重大的问题。
xcstream 2021-01-03 21:28:22 +08:00 10506 次点击这是一个创建于 1808 天前的主题，其中的信息可能已经有所发展或是发生改变。
 | 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 slowman 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 PRO 不是自己写的还是别乱动吧，说不定是 feature 不是 bug，改了出了问题一顿喷你到时候感觉像吃了屎 |
 | 25 jonathanchoo 2021-01-04 08:29:10 +08:00 via iPhone 刚毕业那会我会偷偷改掉 可现在 当没看见 |
 | 26 Tink PRO 自己的 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 8888888888 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 修复工作，你没必要承担因此带来的风险。 |
 | 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 ethusdt 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 julyclde 2021-01-06 16:42:23 +08:00 首先：肯定不要偷偷摸摸修复 其次，是否大张旗鼓，这个看企业文化来定 但至少要有关于这个事来龙去脉的整套追踪 |
Select Language