被 Code Review 折磨疯的组员

[MrRongts]

Code Review 经常性把别人的写的都推翻，让人按照他的想法来，这他妈的是什么个心理。 组里都特么都在吐槽，大环境下没人敢说不，太难了。以前担心被裁员，现在期望被裁员拿赔偿走。

[zsc8917zsc]

既然有 Code Review ，那写之前没定规范吗？

[vfs]

反过来讲： 会不会是自己代码写得不太行？

[DiamondYuan]

ai 时代这些都不是事，让 ai 写就行了。

请按照 xxx 要求修改代码。 修改后保持原有功能不变。

[xing7673]

@vfs 写的都推翻，我是对面的问题更大

[S1ahs3r]

Code Review 已经是眼高手低的伪程序员唯一能发挥的地方了。

见过每次都对命名指手画脚的人么？（都符合命名规范）

[MrRongts]

@vfs 你费劲巴力的写了 2 天, 业务功能也完成了， 功能也测试过了。Code Review 说你这样写不好，有更好的方法，好你在根据他的想法重写，来回 Review, 为了一个他所谓“好” 折腾别人，无非是显自己很优越，我见过组里有人，为这种问题搞了好几周，人都麻了。

[cutecore]

@MrRongts 刚入职会遇到有这种，感觉是看看水平和服从性测试，正式开始开发就没人管了，按时交付就行

[bbao]

@MrRongts 不，可能你真的比较弱，你都说了，费劲吧啦写了 2 天。要从中学习到大家提的建议，或者你有理有据的反驳。都做不到，可能就是，单纯的，比较弱

[vfs]

@MrRongts 打工人是按照时间挣钱的，之前的代码已经挣过钱了，重写的又能重新挣钱 :）

[bojackhorseman]

能跑就行了，功能实现了就行了。搁这写高考满分作文呢，留着家传吗？

[fj24911]

我认为 CodeView 作用有限。
将更多的时间放在前期设计和文档完善收益更大。
单元测试通过了就可以了，对结果负责，过程细节难以掌控。
AI 是个好帮手

[MrRongts]

有次写 js 的时候， 我用了一个 ?? 语法，他问这是什么屌语法改掉。 有次写 rust 的时候， 我使用 HashMap 的时候，

我这样
```
let a = HashMap::new();

if a.contains_key("1") {
a.insert("1", vec![]);
}

a.get("1").unwrap().push("1");
```

然后他跟我说有一个 or_insert, 让我改掉

最早的时候，我经常使用 rust 链式处理方法，他说不好，给我的感觉就是只有他不知道，你就得改

[lambdaq]

你说下次一定啊。

下次写之前让他开个头。

[nananqujava]

现在还有什么弱不弱的, 我用 CC 写, 你咋挑刺?

[Huelse]

个人建议：听劝，他说什么都对，出问题也是推给他负责

[red13]

组员被 Code Review 折磨疯，说明 Leader 不具备管理能力

[janus77]

底层语言奇技淫巧多就会这样。写 java 会有这种苦恼？[狗头]

[MrRongts]

@bbao 很好奇你所谓强到底他妈的是啥。 都特么写一下 CRUD 能特么强到哪里去。 还能写出个花来？，还是发明了个什么设计模式，或者什么牛皮的算法。有些所谓的代码好，都是自我感觉良好罢了。

都是 7 ，8 多年程序员，功能都能实现，保证自己的东西不会出问题，对自己的东西负责。老是把自己想法强加于别人只会适得其反。

[jamesxu]

@MrRongts 这人有点闲得蛋疼，语法糖而已，哪种写法不都行

[Romic]

@vfs #9 有没有可能是双倍的时间挣一分钱，就比如本来晚上 6 点下班，codereview 之后 12 点下班。

[oneisall8955]

看得懂就不错了，语法糖的东西。。。

[qhd1988]

没有 eslint 规则之类的吗?定好规则,让机器 review 呗

[vfs]

@Romic 好吧， 忘记了加班没加班费的情况了

[Seck]

兄弟：世界不是这样运行的，人家也许是面子上过得去就随口提了下，并不是真的要你如何改！
没有业务错误就可以，写代码记住，能运行就别动
世界运行方式很复杂，并不需要认真对待每一个

[cccssss]

兄弟，主动找他要个裁员大礼包走吧，你们不适合

[lizon]

0 总之不爽辞
1 Code Review 的人是谁, 为什么有权让你改?
1.1 组长? Leader? 不爽辞
1.2 组员? 完全可以拒绝或向上申请复议或者全组公开讨论


2 Code Review 应该在测试前之前就做完改完


3 整体重写的情况非常非常少, 是否是开发前的方案设计讨论就不充分


4 针对编码风格, 应该全组讨论制定统一的规范; 如果自己维护的业务在全周期由自己负责, 那你可以随便操, 反正也是鹅心下一个接盘侠; 如果是多人共同维护或者定期轮换, 你也不想维护被别人私自随意操烂的代码吧

[ymz]

@S1ahs3r #5 笑死，我遇见过

[SignUpWithSolana]

之前我的上司不懂 js ，review 我的 pr 叫我把字符串的单引号改双引号，我没反驳，按照他说的改了

[2218675712]

ai 写代码，
ai review ，
ai 根据 review 修复
上线后出 bug ，全滚蛋了

[dlmy]

这说明你们的工作量极度不饱和，不然哪有空折腾这个。

我司对我们的要求是：按时完成项目并按计划交付项目，代码的可靠性、可维护性和安全性被放在次要地位。

[Hanggi]

很简答，他给你 review 代码，不意味着对方的代码是正确答案，你再对他的代码进行 review 就行，更好的写法花点时间肯定能找到更好的，每次对方给你 review ，你就给你就给他 review 更好的写法，然后写个小文章，为什么要这么做，这样你自己能力也能提升，也能让对方知道自己 review 代码的局限性

[sorude]

最恶心的是严于他人，宽以自己的。 自己写的代码各种原因都能过，换成别人的代码化身为架构师的杂总

[iyaozhen]

@MrRongts #12 他是什么角色，是他可以 review 你们，你不能 review 他？

[profchaos]

@SignUpWithSolana 我觉得他很懂，双引号是对的

[JingXiao]

这种活最轻松啊，改就改呗，能让改说明项目也不是很赶啊，不然就让老大决定功能都 ok 了，再改来改去又延期风险。反正给时间不额外加班改这个都能接受

[FrankAdler]

手动实现还是用语法糖这种 review 的时候都要改，这还是太闲了，赶着上线的话锅要全部他一个人背？
正常的 code review 应该是侧重性能问题工程合理性啥的吧，比如 for 循环取数改为批量取，已有的逻辑不要重复实现，逻辑都写在 controller 层，漏掉一些异常处理这些
不然你就让他每种语言出个 lint ，别你写完了他想到哪你们改到哪

[irisdev]

我第一份工作跑路很大一部分原因就是一个比我早两年毕业的睿智 cr 老恶心我