工作中该怎么改 bug？？

[www3]

代码出现了一些 bug （代码由不同的人，不同的任务堆积成） 现在需要修复这个 bug 。bug 原因是其他人的代码没考虑周全造成的

第一种： 找到这个没考虑周全的点 并且打补丁修复它 也不影响到其他的地方 bug 修复好 第二种：修复其他人任务的代码 然后修复好 bug

1 和 2 的主要区别是在修改的 bug 的同时去优化别人的代码

使用哪种方式更好？

[Vegetable]

选一：出色完成任务
选二：一个礼拜后，同事：「哪个伞兵改我代码？给我改出 BUG 了」

[Building]

建议选二，原因: 可以充分了解同事这样写的原因顺便了解整体项目的同时还可以给自己买个教训。

[www3]

有人说 选择 1 的是初级程序员 2 是高级程序员

[Joker123456789]

谁的代码谁改，这是最基本原则，如果写这段代码的人离职了，那就由接手的人改。 切勿妄动别人的代码。

[charlie21]

你改完了 bug 之后遭到同事质疑：谁把我的 feature 改没了？

[debuggerx]

告诉其他人让他们自己改好自己的代码，然后 review 。除非公司统计代码提交量算 kpi 。

[ClericPy]

人多的话, 单元测试覆盖到的可以酌情提个 issue + pr 确认下, 很多情况下彼之 bug 可能吾之设计, 遵循现成的 Github flow 做好协同开发

人少的话, 当面怼过去吧, 想太多没啥意思, 尽量别动别人的代码

开闭原则也是支持扩展不支持直接修改, 自己这边补丁下, 毕竟就算是自己的代码, 也难说知道它的影响范围会多大(当年我写了一个得死了两三年的代码, 我自己都不用了就删了, 后来发现居然被别人引用了...)

[sutra]

看团队分工和曾经的合作经历吧，如果是不确定的，还是需要先和负责这个模块的同事沟通一下比较好吧，问问看，需要对方配合或者是不是我直接改了，让他帮忙 review 一下。

[www3]

@Building @ClericPy @Joker123456789 @Vegetable @charlie21 @debuggerx
采用了方案 1 被说不是最优解 该怎么办呢

[EscYezi]

先一再二。加个容错，再跟写出 bug 的人确认让他自己去改。

[auh]

优先第二种。除非原始代码影响到修复 bug，可以进行修改。千万不要高估这几行代码有多大价值

[pkookp8]

一开始选 1，有点追求了选 2，最后发现多一事不如少一事，选 1 完事

[lap510200]

入行久点你会选 1 有很多人讨厌别人动自己代码，但又喜欢碰别人的，除非你水平和职务远大于他，否则不建议动

[www3]

@EscYezi @auh @pkookp8 @lap510200 感谢，我选择的 1 然后被喷了。

[goxxoo]

屎山缔造者找屎

[lap510200]

@www3 除非没修复兼容好，如果自身技术水平高，直接怼回去，如果是 3 年以内经验，那你还是服从老兵为好，因为你认为需要改动的地方并不一定是最合理的

[lap510200]

@www3 你用第一种没毛病，既然你都问了这个话题，明显就不属于水平和职务远大于他，用 2 的都是团队 leader 或者大佬

[www3]

@lap510200 是的 说的非常对 ，就是目前的状况。这个时候就感觉特别累，感觉不仅的是在对应工作，还是对应人了。
这个这块别人写的不合理 那么请把它改掉 这句话说的简单 做起来难呀