V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
xcstream
V2EX  ›  程序员

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

  •  
  •   xcstream · 2021-01-03 21:28:22 +08:00 · 9448 次点击
    这是一个创建于 1180 天前的主题,其中的信息可能已经有所发展或是发生改变。
    74 条回复    2021-01-06 16:42:23 +08:00
    3dwelcome
        1
    3dwelcome  
       2021-01-03 21:33:01 +08:00   ❤️ 1
    如果是自己写的 BUG,肯定越早修复越好,你并不确定,会不会因为这个 BUG,引发其他关联小问题。
    我觉得吧,衡量一个码农的价值,是看他写的代码有多少人在实际使用。而不是公司里那个最会修 BUG 的人。
    manami
        2
    manami  
       2021-01-03 21:35:01 +08:00 via Android   ❤️ 8
    别动。我也有过类似经历,不公开的 bug 你乱动修最后出问题是要背锅的
    3dwelcome
        3
    3dwelcome  
       2021-01-03 21:37:44 +08:00   ❤️ 2
    @manami 你可真是机灵鬼。
    dji38838c
        4
    dji38838c  
       2021-01-03 21:38:46 +08:00   ❤️ 1
    可以选的另一个态度是:根本不在意。
    无须在意别人怎么看,你想怎么做就做好了,不必最终目的是"让别人觉得如何"
    imdong
        5
    imdong  
       2021-01-03 21:38:47 +08:00
    对于这种问题当然是早发现早治疗,免得贻误时机。

    我相反,有另一个问题:

    发现一个理论上永远无法触发但明确是有 BUG 的代码,要不要修复?
    liuzhaowei55
        6
    liuzhaowei55  
       2021-01-03 21:38:59 +08:00 via Android   ❤️ 4
    千万别动,你以为只是这一个 bug,其实后边还有 n 多依赖此 bug 而写的特性,所以千万别动。
    txdy1
        7
    txdy1  
       2021-01-03 22:06:26 +08:00   ❤️ 2
    @imdong 把这段逻辑删掉
    wangbenjun5
        8
    wangbenjun5  
       2021-01-03 22:10:21 +08:00
    能问出这种问题的人还是年轻,除非以前那段代码是你自己写的,不然永远不要在未和别人沟通过的情况下擅自修改别人代码。。。
    ebony0319
        9
    ebony0319  
       2021-01-03 22:15:43 +08:00 via Android   ❤️ 1
    在你不能完全控制的情况下别动。我之前改过一个,用 get 方法用一堆 id 去查。我发现在 id 过长情况下会 get 方法会报错。于是将请求分为 100 个每组分配查询。当时以为很简单,结果鸡儿里面还有一个排序。第二个就是有一个查询条件,方向他边界没有处理好。给他加了一句。结果字段写错了。后面就悲剧了。
    php8
        10
    php8  
       2021-01-03 22:30:25 +08:00 via Android   ❤️ 13
    有些 bug 活久了就成精变 feature 了,可能有的代码依赖这个 bug 一改就翻车。我亲身经历过这种 bug,改就是作死,偷偷改就是花样作死。
    ujued
        11
    ujued  
       2021-01-03 22:42:06 +08:00 via iPhone
    改,依价值观行事
    lihongming
        12
    lihongming  
       2021-01-03 22:50:26 +08:00 via iPhone   ❤️ 18
    @php8 所以屎山也是山,只要够古老,就会有神仙
    Stictonotus
        13
    Stictonotus  
       2021-01-03 22:57:45 +08:00 via Android
    是自己写的趁早改 不是的话 如果你不能完全理解代码的逻辑那就别动 有的你看上去是 bug 但是人家是个 feature 。。
    renmu123
        14
    renmu123  
       2021-01-03 23:03:31 +08:00 via Android
    你写的就直接改,不是的话就提给产品经理,改不改随他咯
    lscho
        15
    lscho  
       2021-01-03 23:05:02 +08:00   ❤️ 3
    @imdong 理论上永远无法触发,那理论上就不是 bug,修他干啥?修了有钱吗?有钱就修
    zpxshl
        16
    zpxshl  
       2021-01-03 23:07:56 +08:00 via Android
    负负得正的事情我遇到好几次了。
    修了个 bug,引出另一个 bug,后者还更严重...
    akakidz
        17
    akakidz  
       2021-01-04 01:03:53 +08:00 via Android
    提给老大来决定改不改...
    1423
        18
    1423  
       2021-01-04 01:19:44 +08:00 via iPhone
    考虑一下权利和义务对等原则
    msg7086
        19
    msg7086  
       2021-01-04 01:20:55 +08:00 via Android
    如果你和老大关系好,就和他提一下然后开个 ticket 放着。
    BUappend
        20
    BUappend  
       2021-01-04 01:32:15 +08:00 via Android
    @manami 是的,我就背过锅
    akring
        21
    akring  
       2021-01-04 01:37:44 +08:00   ❤️ 3
    上报上级,如果是自己写的,还要同步到测试并建立 Issue Ticket,然后看版本迭代计划安排修复和回归。

    无论是自己私自改还是假装不知道,都要冒着定时炸弹爆炸之后紧急救火的风险,对自己和对团队都不负责任。更何况 Git 记录在那摆着,谁写的 Bug,谁悄悄改了东西没同步测试回归最终引发了其他事故,一目了然,逃避一点都没有用。
    xcstream
        22
    xcstream  
    OP
       2021-01-04 02:51:40 +08:00
    想表达的是扁鹊的问题
    扁鹊:长兄最好,中兄次之,我最差。
    有些事情有益但没成果
    mingl0280
        23
    mingl0280  
       2021-01-04 02:58:28 +08:00
    上报啊,发现 bug,ticket 有记录以后大家都知道了。
    darksword21
        24
    darksword21  
       2021-01-04 07:54:38 +08:00 via iPhone
    不是自己写的还是别乱动吧,说不定是 feature 不是 bug,改了出了问题一顿喷你到时候感觉像吃了屎
    jonathanchoo
        25
    jonathanchoo  
       2021-01-04 08:29:10 +08:00 via iPhone
    刚毕业那会我会偷偷改掉
    可现在
    当没看见
    Tink
        26
    Tink  
       2021-01-04 08:32:30 +08:00 via Android
    自己的 bug 不改等着过年?别人的 bug 告诉他就行了,你别动
    saberlong
        27
    saberlong  
       2021-01-04 08:36:50 +08:00 via Android
    直接提 bug 。
    接下来会安排到某个迭代由某个人解决。
    改的人会分析影响范围。
    改完也有回归测试。
    codyfeng
        28
    codyfeng  
       2021-01-04 08:58:10 +08:00 via Android
    开一个 ticket 描述一下这个 bug,让领导决定如何处理
    gggxxxx
        29
    gggxxxx  
       2021-01-04 08:58:20 +08:00
    立即提出来,但是不要去修改。等大家 review 了后再改是比较稳妥的做法。任何上线了或者已经进入一定阶段的程序,动任何一行代码都牵扯到需要堆人力物力去测试。偷偷修改等于是将当前测试作废。

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

    还有一些代码看上去是有明确 bug 的,但是不太影响使用。我以前工作中遇到过这种情况,我们告诉客户代码发现有 bug,客户直接说别动代码!你们说的那个 bug 我们知道,我们每天重启一次机器就避免了........
    ericls
        30
    ericls  
       2021-01-04 09:13:47 +08:00
    马上公开透明沟通这个问题
    Leonard
        31
    Leonard  
       2021-01-04 09:16:46 +08:00
    如果自己写的就改,别人写的先不要乱动。。
    moonrailgun
        32
    moonrailgun  
       2021-01-04 09:18:50 +08:00
    我就好奇没有 code review 的么。怎么做到偷偷改代码的
    clayyj1210
        33
    clayyj1210  
       2021-01-04 09:36:01 +08:00
    赞同#21 的做法报告上去。不过即使有 Git 记录,有些人也未必看哦。
    NexTooo
        34
    NexTooo  
       2021-01-04 09:36:34 +08:00
    看规模吧。也可以考虑上报先。
    不太建议私自改动,我前阵子改了一句看似没啥用的代码,然后发现在某些情况下出问题了( 才知道这是同事特意这么写的
    不问过同事写这句的缘由和依赖这一段代码的地方,随意乱动可能反而真出 bug 了
    young1lin
        35
    young1lin  
       2021-01-04 09:38:56 +08:00
    不要乱动别人的代码,万一出了更多的 bug,哭都来不及。自己写的,并且了然于胸的,马上改了。代码只有不断重构才能 bug 变少。
    linxl
        36
    linxl  
       2021-01-04 10:15:02 +08:00
    就怕是多米诺骨牌
    kanemochi
        37
    kanemochi  
       2021-01-04 10:18:36 +08:00
    你以为这是一个 bug,建议你看下提交时间,八成是凌晨两三点提交的,福报状态下的产物,很多核心逻辑依赖这个 bug,你不改又不是不能用,你改了出故障你一定凉。
    vincent7245
        38
    vincent7245  
       2021-01-04 10:21:13 +08:00   ❤️ 1
    站在打工人的角度:不管。
    只要动了你就要对后果负责,鬼知道修复这个 bug 会引起什么新的 bug 。
    其次,某天 bug 爆发,跟我有什么关系,公司又不是我的,我只是个打工的。
    dany813
        39
    dany813  
       2021-01-04 10:24:18 +08:00
    不能直接改,可以上报定位下,是否有改动的价值
    Kili9
        40
    Kili9  
       2021-01-04 11:11:31 +08:00
    你以为改好了这个 bug,但你很难发现会不会引发另外依赖性的 bug,如果依赖性太强或者不知道牵扯到其他服务功能的最好跟上级汇报,制定方案,安排产品排期,改完让测试过一遍
    timedivision
        41
    timedivision  
       2021-01-04 11:18:34 +08:00
    自己写的就改,别人写的不改,但是可以跟别人说
    hijoker
        42
    hijoker  
       2021-01-04 11:37:54 +08:00
    @lihongming 大哥,你真是人才
    dorothyREN
        43
    dorothyREN  
       2021-01-04 11:51:31 +08:00
    @imdong #5 理论上 有驾照的人都会开车,理论上开车的人都有驾照。那么问题来了。。。
    dnsaq
        44
    dnsaq  
       2021-01-04 12:47:16 +08:00 via iPhone
    职业素养问题,作为打工人我觉得可以不改但是得有个度。第一可以不改,但不要给他人带来麻烦,不改出问题让运维背锅???第二可以不改但一定要做记录,或者提前想好应对方案便于真出问题的时候及时处理。
    opengps
        45
    opengps  
       2021-01-04 12:52:49 +08:00
    发现 bug 得提出,未必需要你来修复。
    修复这个 bug 并没有被安排成你的任务,如果你的 deadline 时间宽裕,那可以好心去做,然而 deadline 里并没有包含这个 bug 修复工作,你没必要承担因此带来的风险。
    fenglangjuxu
        46
    fenglangjuxu  
       2021-01-04 13:32:40 +08:00 via iPhone
    @zpxshl 我也是 还基本都是修改一行代码导致的
    xsqfjys
        47
    xsqfjys  
       2021-01-04 13:37:08 +08:00
    提出来走个 bug 修复流程呗,有 bug 多正常啊。但是随便改代码没有测试知道没有业务知道万一出了问题就尴尬了
    lakehylia
        48
    lakehylia  
       2021-01-04 13:51:26 +08:00
    不管是自己的 bug 还是别人的 bug,只要上线了,那就报上去决定修不修。修 bug 是要检查相关业务的,所有涉及到的业务线都要做一次回归测试的。
    vanityfairn
        49
    vanityfairn  
       2021-01-04 14:16:32 +08:00
    永远不要在未和别人沟通过的情况,偷偷摸摸 fix,这简直是花样作死,抓到本季度我这儿 kpi 为 0 。可以作为正常得报 bug,然后走 bug 上线流程。同时界定好责任人
    vagranth
        50
    vagranth  
       2021-01-04 14:31:31 +08:00
    自己给自己发一个 bug 然后改掉呗
    soulmt
        51
    soulmt  
       2021-01-04 14:34:55 +08:00
    正常流程: 上报风险, 不要夹带私货,做好了没人奖励你,做不好锅就是你的
    心机一点: 搞清楚 bug 的原因,坐等发作,然后 bug 出来之后像模像样的用最快的速度搞定,可以赚一波 kpi
    jkhere
        52
    jkhere  
       2021-01-04 14:54:38 +08:00
    @imdong 如果一个 bug 永远无法触发的话那就不算 bug 吧
    FaiChou
        53
    FaiChou  
       2021-01-04 15:48:09 +08:00
    放奇葩说上 让他们辩论下吧.
    gongshishao126
        54
    gongshishao126  
       2021-01-04 15:58:27 +08:00
    @ebony0319 只有经历过的人才懂,get 请求由于拼接参数在 url 上,默认长度有限好像是 2k 。参数长度无法估量的最好是改用 post 请求
    hikari2
        55
    hikari2  
       2021-01-04 16:08:39 +08:00
    华佗有两个兄弟,你觉得谁医术最高超?
    qoras
        56
    qoras  
       2021-01-04 16:09:10 +08:00
    自己的 bug,确认改动无影响,偷偷修掉
    同组在职同事的 bug,告诉相应的同事这件事
    同级离职同事的 bug,告知领导,不然你修了做了好事领导不知道,万一出事了还要背锅
    其它组的人的 bug,看心情吧,怎样都行,毕竟现在大部分公司都不尊重程序员的价值
    jsjgjbzhang
        57
    jsjgjbzhang  
       2021-01-04 16:39:08 +08:00
    找个关键时刻 加班解决
    passerbytiny
        58
    passerbytiny  
       2021-01-04 16:58:08 +08:00 via Android
    第一,任何时候都不要偷偷改东西,你改了啥,在提交信息上至少要点一下。第二,在没有保障措施——测试或评审——的情况下,绝对不要改代码。第三,如果没有 QA,或者 QA 只是个摆设,或者 QA 不管过程,或者 QA 只是个测试,那你干什么都行。
    nomemo
        59
    nomemo  
       2021-01-04 17:33:53 +08:00
    报出来,改不改再说。
    jiumingzhu
        60
    jiumingzhu  
       2021-01-04 17:53:50 +08:00
    离职同事写的代码,未上线.接手项目后发现有 bug,权衡了方法的复杂度和 debug 耗时后,我直接重写了那个方法 233
    fumeboy
        61
    fumeboy  
       2021-01-04 17:56:12 +08:00
    善战者无赫赫之功
    GX88624
        62
    GX88624  
       2021-01-04 17:59:23 +08:00
    别动只要不是严重的 bug,当他不存在.严重的先报告,不过你报告了,这估计要你处理了.
    securityCoding
        63
    securityCoding  
       2021-01-04 18:06:47 +08:00
    静下来梳理下 bug 影响范围 , 让领导和团队都知道这个事情 ,然后排期开始干
    pixiaotiao
        64
    pixiaotiao  
       2021-01-04 18:47:27 +08:00 via Android
    我改过,改出了更大的 bug,还好没人发现。
    flowercoder
        65
    flowercoder  
       2021-01-04 20:08:47 +08:00
    有测试吗环境吗?有的话可以改完试,试完没问题再提交。
    没测试环境就别改了。
    你们领导懂不懂代码,不懂的话也可以改,懂行的话就别改了,除非发现 bug 再改。
    lidlesseye11
        66
    lidlesseye11  
       2021-01-04 20:40:42 +08:00
    @xcstream
    你的意思领导是昏君了?
    发现了一个潜在的 bug 怎么会是没成果。。
    cooker498
        67
    cooker498  
       2021-01-04 21:51:28 +08:00
    提技术需求
    thetbw
        68
    thetbw  
       2021-01-04 22:42:23 +08:00 via Android
    idea 可以看出哪里调用了这个方法,不过我一般不会改吧,顶多在上面加个 @Deprecated 或者 FIXME
    renzituo
        69
    renzituo  
       2021-01-04 22:50:35 +08:00
    有些 bug 用户使用时间久了就当成正常的了,你改了反而成了 bug 。 曾经做新业务的时候碰到一个老逻辑的「 bug 」,明明未读却要往已读的逻辑里跑,顺手改完后,还测试了,结果好家伙,整站 N 多投诉 ,说一下子出现好多未读数,我花了一天时间跟各个领导解释 为什么这个不能算 P1 bug
    akring
        70
    akring  
       2021-01-04 23:09:27 +08:00
    @renzituo #68 大哥你们改完 Bug 不过测试的咩?
    akring
        71
    akring  
       2021-01-04 23:10:08 +08:00
    @renzituo #68 Sorry 没看仔细,这种过了测试还出问题的感觉就得一人一半责任了
    James369
        72
    James369  
       2021-01-05 10:04:04 +08:00   ❤️ 1
    我想贴一幅经典的动图,就是有一只小熊在修理水管。。 怎么贴
    tankren
        73
    tankren  
       2021-01-05 13:42:51 +08:00
    要看上线了多久吧 遇事不决找领导
    julyclyde
        74
    julyclyde  
       2021-01-06 16:42:23 +08:00
    首先:肯定不要偷偷摸摸修复
    其次,是否大张旗鼓,这个看企业文化来定
    但至少要有关于这个事来龙去脉的整套追踪
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5329 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 08:08 · PVG 16:08 · LAX 01:08 · JFK 04:08
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.