代码出现了一些 bug （代码由不同的人，不同的任务堆积成）
现在需要修复这个 bug 。bug 原因是其他人的代码没考虑周全造成的
第一种： 找到这个没考虑周全的点 并且打补丁修复它 也不影响到其他的地方 bug 修复好
第二种：修复其他人任务的代码 然后修复好 bug
1 和 2 的主要区别是在修改的 bug 的同时去优化别人的代码
使用哪种方式更好？

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

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

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

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

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

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

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

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

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

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

采用了方案 1 被说不是最优解 该怎么办呢

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

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

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