工作中该怎么改 bug??
代码出现了一些 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 完事
引言 今天写代码,发现bool不能直接强转成int,这就导致如下代码编译错误 type Status int const StatusSuccess Status = 1 ..…
服务器的私钥、软件的证书平时一直放在桌面上的文件夹里,担心被扫盘的软件扫走已知的有卡巴斯基,可以在有软件读取特定文件的时候询问用户是否放行火绒似乎也可以除以上两个还有没有其他安…
新机,二手均可,不打游戏,希望屏幕舒服,有高刷就行,大家有推荐嘛。 realme 大探,小米 10s ,iqoo neo5 ,红米 k40 。。。。纠结了 K40 到手刷个 …