这是一个创建于 972 天前的主题，其中的信息可能已经有所发展或是发生改变。
代码出现了一些 bug （代码由不同的人，不同的任务堆积成） 现在需要修复这个 bug 。bug 原因是其他人的代码没考虑周全造成的
第一种： 找到这个没考虑周全的点 并且打补丁修复它 也不影响到其他的地方 bug 修复好 第二种：修复其他人任务的代码 然后修复好 bug
1 和 2 的主要区别是在修改的 bug 的同时去优化别人的代码
使用哪种方式更好？
 |
1
Vegetable 2021-08-20 18:34:31 +08:00  1
选一：出色完成任务
选二：一个礼拜后，同事：「哪个伞兵改我代码？给我改出 BUG 了」 |
 |
2
Building 2021-08-20 18:52:52 +08:00 via iPhone 1
建议选二，原因: 可以充分了解同事这样写的原因顺便了解整体项目的同时还可以给自己买个教训。
|
 |
3
www3 OP 有人说 选择 1 的是初级程序员 2 是高级程序员
|
 |
4
Joker123456789 2021-08-20 19:05:30 +08:00 2
谁的代码谁改，这是最基本原则，如果写这段代码的人离职了，那就由接手的人改。 切勿妄动别人的代码。
|
 |
5
charlie21 2021-08-20 19:11:13 +08:00 1
你改完了 bug 之后遭到同事质疑：谁把我的 feature 改没了？
|
 |
6
debuggerx 2021-08-20 19:13:42 +08:00 via Android 1
告诉其他人让他们自己改好自己的代码，然后 review 。除非公司统计代码提交量算 kpi 。
|
 |
7
ClericPy 2021-08-20 19:21:06 +08:00 1
人多的话, 单元测试覆盖到的可以酌情提个 issue + pr 确认下, 很多情况下彼之 bug 可能吾之设计, 遵循现成的 Github flow 做好协同开发
人少的话, 当面怼过去吧, 想太多没啥意思, 尽量别动别人的代码 开闭原则也是支持扩展不支持直接修改, 自己这边补丁下, 毕竟就算是自己的代码, 也难说知道它的影响范围会多大(当年我写了一个得死了两三年的代码, 我自己都不用了就删了, 后来发现居然被别人引用了...) |
 |
8
sutra 2021-08-20 20:04:21 +08:00 1
看团队分工和曾经的合作经历吧，如果是不确定的，还是需要先和负责这个模块的同事沟通一下比较好吧，问问看，需要对方配合或者是不是我直接改了，让他帮忙 review 一下。
|
|
9
www3 OP |
 |
10
EscYezi 2021-08-20 20:12:32 +08:00 via iPhone
先一再二。加个容错，再跟写出 bug 的人确认让他自己去改。
|
 |
11
auh 2021-08-20 20:18:03 +08:00
优先第二种。除非原始代码影响到修复 bug，可以进行修改。千万不要高估这几行代码有多大价值
|
 |
12
pkookp8 2021-08-21 10:18:32 +08:00 via Android
一开始选 1，有点追求了选 2，最后发现多一事不如少一事，选 1 完事
|
 |
13
lap510200 2021-08-23 09:33:29 +08:00
入行久点你会选 1 有很多人讨厌别人动自己代码，但又喜欢碰别人的，除非你水平和职务远大于他，否则不建议动
|
 |
15
goxxoo 2021-08-23 11:00:13 +08:00
屎山缔造者找屎
|
|
16
lap510200 2021-08-23 11:32:32 +08:00 1
@www3 除非没修复兼容好，如果自身技术水平高，直接怼回去，如果是 3 年以内经验，那你还是服从老兵为好，因为你认为需要改动的地方并不一定是最合理的
|
Select Language