一到我提 pr 就各种意见，看到我加了锁就想起来这里是多线程/进程读写了
加了还不够，有没有考虑这个锁没生效？会不会死锁？锁的时机对不对？
明明我就是复制粘贴其它文件的代码，别人从来没关心过这个问题也没事
我要是直接只改改名字也就过去了，非得考虑这一下反而给自己找不痛快
review 的时候我都没敢说我是复制粘贴的，不然指不定让我把其它地方全改一遍
代码里一堆烂事，已经没有一开始的热情去优化了，多做多错，能者多劳
 | 1 prosgtsr 18 天前  1 他作为 review 你代码的人，这么做是负责任的表现，你不能因为这个去怪他 还是保持对代码的热情吧。 |
 | 2 chendy 18 天前 没看出哪里奇葩，倒是觉得楼主这个工作很适合 AI 来干  |
 | 4 xiangran0028 18 天前 复制粘贴代表没问题吗？ |
 | 5 Meursau1T 18 天前 这种我都是自己把他的问题塞给 AI 让 AI 帮我处理的，如果不需要处理也可以复制 AI 的回复，给自己少点不痛快 |
 | 6 300 OP |
 | 7 wu00 18 天前 1 哈哈，遇到过这种情况，有些人老觉得自己被针对被审视 之后我就很少干 cr 这种吃力不讨好的事情了，除非核心模块 |
 | 9 njutree 18 天前 你是刚加入这个组嘛，如果是刚到这个组更严厉的 review 是正常的确保你能和大家的规范保持一致。如果不是就是相对被针对了，不一定是恶意的就是某种习惯，组里有人太大佬或者其它原因导致别人 review 的时候不太敢提意见，所以很多过度的 review 就到你这了。我还遇到过 review 的时候觉得你代码规范不对，结果发现整个仓库都是这样风格，结果 block 了 PR 组里人一起讨论新的代码规范，然后改所有其它代码的情况。甚至在 block 或者 review 期间风格又发生了新的变化，陷入无限循环 review 的情况。 这都是很正常的只要需求不急不催你，有 review 改就是了没啥大不了的。麻烦的就是同时有很多 PR 需要频繁的切多个分支改多个地方的代码，然后不停的变。 |
 | 10 YanSeven 18 天前 4 所以楼主吐槽的是一个公平性问题，跟代码无关是吗，本质是： “凭什么对别人宽松打马虎眼，对我就这么严找事儿？” |
 | 11 8355 18 天前 你需要很清楚的知道你提交的代码执行逻辑是怎么样的 你提交的代码你负责啊，是因为你没办法解释你的 pr 的代码所以你觉得被为难了吗 |
 | 12 Q980q48Jgj6pRXoO PRO 这个心态更要认真地 review 你 |
 | 13 27v2er 18 天前 组内有个和 op 类似的同事，review 的时候说的最多的一句话就是：这是我复制粘贴的…，以至于每次 review 到他那里，大家都是每行每段认真看，每次都能找出很多问题，上周刚提桶。 我想说的是可能你有类似的槽点，以至于每次都要被特殊照顾。编码最重要的是严谨的编程思维闭环，尽可能做到滴水不漏，把自己写的代码当成自己的亲儿子。很显然 op 没认识到这一点 |
 | 14 fregie 18 天前 别人能犯错但是你不能犯错,所以心理不平衡是吧,能理解 |
 | 15 vegeta2ex 18 天前 能理解你的心情，大概就是新的功能需求整体框架是拷老的需求框架，里面具体逻辑自己实现。但是 review 的时候偏偏说你的有问题，老功能跑了这么久也没问题，没见有人去优化 |
| 16 300 OP @27v2er 最后说反了，实际上只有我会去考虑代码严不严谨。正是因为我严谨他们看到不一样才不断试图找我问题 还有一个点就是他们并不是看到了问题才问我，而是让我解释给他们听为什么要这么加锁，会不会没用。这种带点脑子自己去看不就完了么，也没什么很复杂的逻辑 |
 | 17 shunia 18 天前 1 既然是复制粘贴的代码那不是太好了吗？没必要去抵触。 直接告诉大家这是复制粘贴的代码，如果需要优化，最好能把上下游都修复一下，这样就需要扩大 scope ，需要重新考虑实现计划，需要对这份复制粘贴的代码做优化计划。 然后告诉 reviewer 我是很愿意改的，这样能给项目带来价值，但是需要确认一下是不是应该在当前花时间做这个优化。要是不打算现在改，或者事件不够，可以加一个 annotation 或者 TODO ，将来去做优化。 事儿不就结了？ |
 | 18 COW 17 天前 你是新人吗，也许他们只是还不够信任你。其实 PR review 里的 comment 也是你提高自己技术影响力的舞台，不要浪费啊，抱怨反而是最没有意义的。 |
 | 19 kevon4096 17 天前 我以为是贞操锁，哈哈哈哈哈，面壁去。。。。 |
 | 20 7beloved 17 天前 组里碰到你这种人，前两次会认真帮你 review ，后面出了问题自己担着去 |
 | 21 SmithJohn 17 天前 有没有类似功能,如果有的话直接别人怎么写你也怎么写呗. 问你你就说参考了哪一段,出于什么考虑改了哪些. 刚进来的就不要表现的太不一样了,不然很容易被针对吧. |
 | 22 aliveyang 17 天前 via Android 不用跟人家比，自己对自己负责就行 |
 | 23 exonuclease 17 天前 多线程的代码我自己写起来也会很小心 因为这玩意容易写错。。。 |
 | 24 abolast 17 天前 会不会是历史遗留问题，之前为了产出不严，现在到了严的时候，也就是看到了就整改。我觉得没问题啊，把自己的排期加嘛，找项目说明原因拉大佬出来刚刚看么 |
 | 25 patrickpu 17 天前 有些人是性格问题，不熟的话一开始有攻击性的，以为提 pr 的都是新手全公司就他最牛逼，code review 的时候喜欢用些强语气词增加沟通矛盾 |
 | 26 edisonwong 17 天前 换个角度想：如果因为你写的这段线上故障了，人家 review 也是帮了你 如果你杠说：”我都是 copy ，别人以前旧代码本来也是屎山“，那人家跑这么久了不也没崩？反正谁维护谁倒霉哈哈哈 |
 | 27 th00000 17 天前 有人愿意认真 review 我的代码，愿意花费自己工作的时间跟我讨论我代码中的问题，我愿意称他一声义父！ |
 | 28 wwd179 17 天前 #10 说得比较明白了。 |
 | 29 donaldturinglee 17 天前 via iPhone 对 concurrency 来说 review 严格一点其实没有什么坏处。如果是 pr 区别对待的话，那就是职场问题了 |
 | 30 sampeng 16 天前 这个我碰到过很多很多了。我觉得是心态问题，不是每个人都热爱代码。做 review 的人我觉得没什么问题，只要不是 review 所谓代码风格其实无所谓。但锁这种东西，你不能说因为别的地方没人管就我这 review 到了你要管我。因为还一个可能，你所谓拷贝的代码可能是 10 年前的，没人敢动。所以不清楚你的实际情况无法评判。实话说，review 如果都是 lz 这种态度，这个 review 的效果是奇差的。code review 在国内还是很难执行下去的。我 review 两次，如果一次不搭理我，我第二次就不管他了。也不再 review 代码，何必起矛盾。 |
Select Language