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

到底改还是不改

  •  3
     
  •   guoyuchuan · 2018-03-19 10:53:54 +08:00 · 8181 次点击
    这是一个创建于 2423 天前的主题,其中的信息可能已经有所发展或是发生改变。

    看见了同事写的一段代码不严谨,数据多了会出错,心痒痒想给改过来,但是怕改了项目会出错,不改看起心里总不是滋味,纠结。你们遇到同事的代码不严谨会怎么去做(修改比较麻烦的那种)?

    46 条回复    2018-03-20 14:39:36 +08:00
    hhacker
        1
    hhacker  
       2018-03-19 10:56:30 +08:00   ❤️ 30
    可以提醒同事,改不改是他的事,但是!
    你不要改!
    你不要改!
    你不要改!
    ofnh
        2
    ofnh  
       2018-03-19 10:56:31 +08:00 via Android   ❤️ 1
    提交 bug,让他自己改
    HuHui
        3
    HuHui  
       2018-03-19 10:57:26 +08:00 via Android   ❤️ 1
    你们缺个 QC
    p2pCoder
        4
    p2pCoder  
       2018-03-19 10:57:48 +08:00   ❤️ 1
    不要动别人的 bug
    20has
        5
    20has  
       2018-03-19 10:59:40 +08:00 via Android   ❤️ 1
    @hhacker 简直不能再同意了!
    depress
        6
    depress  
       2018-03-19 10:59:51 +08:00   ❤️ 1
    提醒,别动,只要你动过的代码以后出事都是你的问题,如果他不改,只要不影响你,当没看见,影响你的话找上级
    alexnone
        7
    alexnone  
       2018-03-19 10:59:54 +08:00   ❤️ 1
    头像好评.
    不要改.可以提醒.
    提醒的方式也很多.看你想怎么处理了.
    guoyuchuan
        8
    guoyuchuan  
    OP
       2018-03-19 11:02:19 +08:00
    @hhacker 阔怕
    @ofnh 小公司,没这个说法,都是各管各的,测试遇到到错误就自己改
    Kilerd
        9
    Kilerd  
       2018-03-19 11:58:51 +08:00   ❤️ 1
    坚决不改,提 BUG 最好,如果不行就帮他加个测试用例,复现这个 BUG 告诉他。
    wizardoz
        10
    wizardoz  
       2018-03-19 13:08:25 +08:00   ❤️ 1
    别人写的让别人自己改。
    如果非要你改,先写好充足的单元测试,用单元测试保证修改后代码的正确性。
    ChenXuting
        11
    ChenXuting  
       2018-03-19 13:10:28 +08:00 via iPhone   ❤️ 1
    楼主这个头像搞得我想举报。<(`^´)>
    abccba
        12
    abccba  
       2018-03-19 13:11:58 +08:00   ❤️ 1
    @ChenXuting me too...
    Oo0
        13
    Oo0  
       2018-03-19 13:23:13 +08:00   ❤️ 1
    @ChenXuting 不是很正常嘛。<
    zhuangzhuang1988
        14
    zhuangzhuang1988  
       2018-03-19 13:25:21 +08:00   ❤️ 1
    自己千万别修改
    linus3389
        15
    linus3389  
       2018-03-19 13:37:11 +08:00   ❤️ 1
    不要乱改别人的代码,git blame 引发真人 PK 可不好玩
    viator42
        16
    viator42  
       2018-03-19 13:42:01 +08:00   ❤️ 1
    提醒一下就行了,如果他听的话就说说修改方案,不听的话就等他翻车好了
    xrlin
        17
    xrlin  
       2018-03-19 13:44:09 +08:00 via iPhone   ❤️ 1
    提醒一下就行了,最好不要自己改。
    QK8wAUi0yXBY1pT7
        18
    QK8wAUi0yXBY1pT7  
       2018-03-19 13:50:41 +08:00   ❤️ 1
    提醒,代码上加注释、标记
    yy120345
        19
    yy120345  
       2018-03-19 13:52:03 +08:00   ❤️ 1
    可以提醒同事,改不改是他的事,但是!
    你不要改!
    XinLake
        20
    XinLake  
       2018-03-19 14:33:14 +08:00 via Android   ❤️ 1
    这种事情你以后可能还会碰到,你不要随便去改。

    告知你上级,程序有问题,为什么有问题,有原因、解决方案、参考资料更好。

    最好开个会,你自己,程序开发者,能做主的人,有技术判断能力的人,这 4 种人都要参与。
    Paddington
        21
    Paddington  
       2018-03-19 14:39:14 +08:00   ❤️ 1
    看来你们没有 code review。

    千万别动!
    千万别动!!
    千万别动!!!
    af463419014
        22
    af463419014  
       2018-03-19 17:20:54 +08:00   ❤️ 1
    做一个能复现 bug 的测试样例,让他改
    自己千万别动!千万别动!!
    happyzed
        23
    happyzed  
       2018-03-19 17:21:56 +08:00   ❤️ 1
    code review
    otakustay
        24
    otakustay  
       2018-03-19 17:40:44 +08:00   ❤️ 3
    看了这楼,我总算是明白公司好和不好的差距,明白技术氛围是什么意思了……
    huluhulu
        25
    huluhulu  
       2018-03-19 17:46:52 +08:00   ❤️ 1
    提交 BUG,让他自己改自己测...
    XinLake
        26
    XinLake  
       2018-03-19 17:55:20 +08:00 via Android   ❤️ 1
    @otakustay

    技术部门,技术工作,但是正能量技术导向、科学准确导向的公司不多见。
    建自己小王国,家族化,倒是容易见。
    yrom
        27
    yrom  
       2018-03-19 18:48:41 +08:00   ❤️ 1
    原来。。。是这样的吗

    看来要改改我手痒的毛病了 눈_눈
    abccba
        28
    abccba  
       2018-03-19 18:53:57 +08:00   ❤️ 2
    @otakustay 我的看法:
    如果在一个鼓励“追求卓越”,真正有技术氛围的团队(部门、公司),团队 leader 和同事都是有追求的人,那么可以自己去改。
    但是,国内大部分公司(团队)都不是那样的,包括几个一线公司的(绝)大部分团队(亲身经历、对周围的观察)。这种情况下,那么做,数学期望上对个人来说是负作用的。劣币驱逐良币?囚徒困境?

    当然,应该还是有理想中的团队的,但幸运的人毕竟是少数?
    绝大部分人都是普通人,不是那种能力挽狂澜的神人;可以试着用自己的行为去影响周围人,但不要抱太大希望。

    我的建议是,楼主可以先评估下风险,和 leader 讨论下,如果得到肯定,可以尝试去改动。当然,要做好最坏的打算和心理准备。我刚工作时也像楼主一样,看不惯的小地方也愿意去改,有时候即便没有引入 bug,也会有各种各样的问题(包括无意义的扯皮),就会发现不是“改几行代码”那么简单,有些打击积极性。这种事情做多了就会发现,其实也是耗时间和精力的,但付出了不一定会得到认可。不过,楼主你想做的事情,如果代价不是很大,还是尝试一下吧,如果尝试一下觉得有意义,可以坚持;如果觉得受挫了,再平凡地活着,就像大部分人一样,其实也行?

    最后,就算影响不了周围人,自己也要保持追求卓越的态度,自己的代码要好好写。
    我们一路奋斗,不是为了改变世界,而是为了不让世界改变我们。——《熔炉》
    otakustay
        29
    otakustay  
       2018-03-19 19:18:34 +08:00   ❤️ 1
    @abccba 是的,我总结出来是这么几条,不要怪我太严厉:

    1. 技术氛围真的是区分团队好坏的一个东西,我现在能理解为什么有人会在我厂工资没竞争力的情况下选择留下了
    2. 我在 V2EX 上也看到过很多人抱怨团队氛围不好,但从这个楼来看,我有一个疑问:氛围是不是就是楼上这些人搞出来的?
    3. 无论团队的氛围是怎么样的,当出现问题时抱着这样的态度,作为一个个人,已经离“成长为优秀”越来越远了
    4. 正确的办法难道不是:自己修一修,但可以不上线,然后找不找人去聊另说,总之遇到好玩的想写的代码当然第一时间写上去啊
    surfire91
        30
    surfire91  
       2018-03-19 19:56:42 +08:00   ❤️ 1
    我就不服楼上两个能说到团队技术氛围上去。我赞成说通知维护者但是不私自改的,因为在某些复杂的情况下,你不一定分得清是 feature 还是 bug。
    Him
        31
    Him  
       2018-03-19 20:10:11 +08:00   ❤️ 1
    你不会用嘴说吗
    abccba
        32
    abccba  
       2018-03-19 20:13:22 +08:00   ❤️ 1
    @surfire91
    一般的做法或者工作流程来说,没法私自改吧。不知道你们是什么开发流程,我们这边是先和模块负责人沟通,之后写完代码强制发 code review,通过 cr 才有权限 commit.
    如果要自己改,肯定是需要和同事沟通的。
    abccba
        33
    abccba  
       2018-03-19 20:22:59 +08:00   ❤️ 1
    对哦,应该先和原作者沟通下。如果他完全不想管,那你再决策。
    如果他很乐意修复,你可以和他先讨论讨论修复方法,有强烈兴趣可以毛遂自荐去解决 ==
    nullen
        34
    nullen  
       2018-03-19 20:30:58 +08:00   ❤️ 1
    不要改.
    gravitybox
        35
    gravitybox  
       2018-03-19 20:31:45 +08:00 via Android   ❤️ 1
    交流一下吧
    akira
        36
    akira  
       2018-03-19 23:16:14 +08:00   ❤️ 1
    不要私自去动别人的代码.
    不要私自去动别人的代码.
    不要私自去动别人的代码.
    NxiJSiOS
        37
    NxiJSiOS  
       2018-03-19 23:36:19 +08:00 via iPhone   ❤️ 1
    让他自己改
    Leigg
        38
    Leigg  
       2018-03-20 00:26:28 +08:00 via iPhone   ❤️ 1
    不说话,让他翻车
    lattemint
        39
    lattemint  
       2018-03-20 02:30:34 +08:00
    提醒他吧,他不改是他的事情。还有你这个头像我点了两次了…………
    johnnie502
        40
    johnnie502  
       2018-03-20 05:01:43 +08:00   ❤️ 1
    出错再改,而且别人写的代码,可能有些地方已经考虑过了,你觉得会出错的地方,其实是不会被执行到的。没有真凭实据就不要费这个劲了
    scipio
        41
    scipio  
       2018-03-20 08:44:34 +08:00   ❤️ 1
    不要自作主张地改!
    不要自作主张地改!
    不要自作主张地改!

    但是作为一个团队而言,最好也不要视而不见。

    我个人建议:

    你觉得这段代码有问题的话,最好能构建一个能让这段代码跑出问题的用例:

    - 如果你们有较完善的 BTS,就直接提 BUG 出来,并把你的定位结果也附上去。

    - 如果你们只是一个不太正规的小团队,那么就喊上这部分代码的负责人,以及你们的 Leader 聊一下这个事情,先把问题抛出来(这里的建议是: 千万不要一上来就说人家的代码有问题。而是一上来只谈你的用例)。如果大家都认为这是个问题了,你可以提出你调查的结果(即 xxxx 的 xxx 代码有问题)说出来。如果连 Leader(负责人)都不认为是个问题的话,那就不要再继续往下聊了。但最好能形成一个简单的备忘录来证明你组织大家讨论过这个问题,结论是啥啥啥。省得万一以后有什么衍生问题发生时,别人责怪你没早把问题提出来。
    jimi2018
        42
    jimi2018  
       2018-03-20 08:46:54 +08:00   ❤️ 1
    提醒一下不就 ok 了吗。
    cxh116
        43
    cxh116  
       2018-03-20 09:10:02 +08:00 via Android   ❤️ 1
    不改。
    看人,对方是对技术有追求的话,提醒一下,否则当作没看见。


    @otakustay 技术氛围是技术 leader 搞出来的。当 leader 有工具格式化不格式化,要打空格的地方不打空格,导致代码都不能正常高亮,虽然能运行。没错,只要能运行就行了。

    你作为下属要去大谈代码质量吗?

    所以,
    只跟同道中人谈追求。

    这些都不是问题,给的工资过的去就行了。
    uuus007
        44
    uuus007  
       2018-03-20 11:08:54 +08:00   ❤️ 1
    很多时候你看的问题都有其内在的逻辑。 可以询问同事,你的想法对不对。 但是千万不能你来改
    千万不能你来改
    千万不能你来改
    千万不能你来改
    annielong
        45
    annielong  
       2018-03-20 14:27:42 +08:00   ❤️ 1
    这个和氛围什么的没关系吧,作为程序员肯定不能私自动别人的代码,尤其是 GIT 的公共环境下
    miemiekurisu
        46
    miemiekurisu  
       2018-03-20 14:39:36 +08:00   ❤️ 1
    Please DO NOT touch anything if it still woks well now, unless you REALLY KNOW what you're doing.
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1255 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 23:10 · PVG 07:10 · LAX 15:10 · JFK 18:10
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.