被 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 打工人是按照时间挣钱的，之前的代码已经挣过钱了，重写的又能重新挣钱 :）

[dumbass]

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

[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 链式处理方法，他说不好，给我的感觉就是只有他不知道，你就得改

[tf2]

你说下次一定啊。

下次写之前让他开个头。

[nananqujava]

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

[Huelse]

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

[red13]

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

[rb6221]

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

[MrRongts]

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

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

[jamesxu]

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

[Romic]

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

[itechify]

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

[qhd1988]

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

[vfs]

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

[Seck]

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

[cccssss]

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

[x8]

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


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


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


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

[ymz]

@S1ahs3r #5 笑死，我遇见过

[SignUpWithSolana]

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

[litmusF]

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

[midsolo]

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

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

[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 老恶心我

[NotLongNil]

code review 有没有给出合理的理由？如果有，建议你心平气和的想想对方的理由是否合理。如果没有，就是纯粹的服从性测试，不敢辞就忍

[charlie21]

给钱了吗？拿钱了就改啊

[kristofer]

比较优秀的做法是：每一次 pr 都有 review ，而不是全都写完了，QA 都测完了才 review ，然后重写，这样会导致 QA 也要重新测试。

[digitv]

组员是你领导吗？是的话让你咋改就咋改，不是的话，难道你是怂 B 吗？你不改能把你吃了还是咋地

[MrRongts]

@dynastysea 当然是领导啊，要组员不得怼死他。

[MrRongts]

@JingXiao 一点都不轻松，经常性的推翻重来，谁能受得了，关键我特喵的也记不住他的哪些吊想法，问多了，还得挨批。提交个 mr 战战兢兢的。

[digitv]

@MrRongts 那领导还说个毛线，要么辞职要么忍

[v2exe2v]

这就是某些人的执念，所以只能做做程序员

[xuanbg]

@S1ahs3r 你还别说，就一个 key 命名的问题，我一不留神就给我乱来，搞得现在要半夜起来更新数据改这该死的 key 。

[MrRongts]

@dlmy 忙的时候，MR 就堆在哪里，堆个 10 几 20 个一点不夸张，交付的时候经常出现合并冲突，然后丢代码，然后又让我们去改。

闲的时候，开始 review 了，一行一行的看, 写的跟他想法不一样，就要按他的想法来，重写，你还得拿笔记，想想心里都堵的慌。

[MrRongts]

@dynastysea 裸辞太亏了，放开了，准备开怼了。混个 n+1

[Ketteiron]

@profchaos #34 哪对了，这不就是代码风格不同，还能分个高下的。
那分号结尾对不对，尾随逗号对不对，箭头函数括号对不对，实验新三元组对不对。
只要有统一的代码风格强制限定，无论怎么配置我都认为对，反之无论怎么写都是错。

[inyfee]

我以前也是被 code review 折腾了一会儿，总要按照对方的方式来改。有时候就是口味不同而已。 并没有写法的高低。

后来，我们在写代码之前会大致把开发方案先写出来，一起过一下，再开始开始，这样的话，后面的 code review 只会看一眼代码的风格，代码的方向可以不用再有纠结的地方了。

[jhdxr]

光看这个帖子：『 Code Review 经常性把别人的写的都推翻』，也很有可能是 reviewer 觉得自己带了一堆菜*还感觉无论如何都带不动那种

但看了你上个帖子里的例子，怎么说呢。 我觉得要是有**更**合理的理由（比如要支持上古的 IE ）其实 reviewer 的写法的确有道理，只是讨论可读性的话在这个例子上过于牵强，除非其他人都是上古程序员。。。

[hzj629206717]

珍惜认真 Review 你代码的人吧。大多数人水平真的很一般可能自己还认识不到。
如果 Leader 的技术追求，技术审美，和技术水平都比你高，你就多学习学习。

[NoobPhper]

@MrRongts unwrap 不 panic 了么...

[Tomfe]

感觉有的人好像被 pua 习惯了 这种 leader 可不一定是有啥技术追求 单纯就是想搞一言堂 把组员当 AI 用 这种真就别忍着 你忍不住的 早点摆烂等着大礼包就得了

[SmiteChow]

风格统一是必要的，风格由谁定，当然是你的领导。

[runzekk]

你的 leader 也很无奈，不 review ，其他组的 leader 看到了不符合规范的代码，不显得自己也很菜么。review 吧，是人都讨厌别人找问题，重复工作，下面的人有意见，很难的。 所以我都是带着其他组员，开大会 review ，把火力分散出去，大家都觉得你写的有问题，那你大概率有问题了。

[guyeu]

明显是流程的问题，code review 应该小步快跑，每个 commit 的内容少一些，反馈快一些，这样就不会改了一大堆全部被推翻。review 过了之后才会接受这个 merge ，才能进入功能测试流程呀，这样就不会出现产品上线等你这个 review 的修复了。

[mysunshinedreams]

我在阿里进行 code review 的时候，committer 面对我提的意见会说：你提的建议我都理解，但是这个需求是 XX 老板点名今天晚上要上的，现在马上管控了，如果上不了这个锅你来背，之后我都是秒点通过。

[ElmerZhang]

这说明你们在 code review 之前还应该再有一轮 design review 呀

[Akiya]

到代码这一步才发现全部需要推翻重写的话，说明前面的流程完全没用

[Sfilata]

要是我的话就无所谓，你让我咋改我咋改。又花不了几分钟，如果要重新实现就评估工期呗，这种爷说爷有理，婆说婆有理的事情怎么可能说得清楚。在团队中多人协作妥协是很正常的事情，如果这都要生气那去开源项目提 PR 几十个人 Review 你受的了？

[Sfilata]

@Sfilata 再说了，如果他能一视同仁的话也在另一层面上保证了代码风格和设计风格的一致性。只要保证功能不出大乱子也不是啥坏事。如果自己真有代码洁癖自己项目爱咋搞咋搞，不是自己的只要不是太离谱太明显的错误就按别人的来。

[sfz97308]

我一直坚持提交符合团队规范的、命名合理、结构清晰的代码，坚持每个 PR 都只干一件事、并且在 PR 描述中详细写明修改背景、Before/After 对比截图、如何测试。
同时，我也是团队中 review PR 最多、对其他人的 PR 提 comment 最多的。好在因为我自己的代码和 PR 质量有目共睹，所以目前还算有点威信，大家看到我提的 comment ，如果合理也都会接受，如果有疑问会一起探讨。

当然，团队大了自然什么人都有，也有觉得我是“blocker”的，甚至私底下搞小动作，想要推动不允许与 feature 不直接相关的人 review 代码。他们会认为“这只是个名字，不重要”，“这种格式问题是小事儿“。他们的 repo 里，PR 几乎没有 comment ，都是直接 approve 了 -- 代码质量真的这么好吗？应该不是的，线上问题一点都不少。

老板们当然不会在意代码质量，所谓的可维护性，在他们眼里也只是明天才有可能出现的问题。他们更希望的是，今天提了需求，明天就能马上上线，严格的 code review 自然会让这个过程变慢。

但是开发者自己还是应该有点追求的吧！但是看到评论区的氛围，下面肯定要有人喷我了，就这样吧，现实还是得接受

[jciba5n4y6u]

@mysunshinedreams

阿里还有啥好说的，企业文化在那摆着呢。


op 不在理，团队合作不是自己关起门来拉屎。厕所管理员的工作做得挺到位的，防微杜渐，不以恶小而为之。

[yuanxing008]

所以从你发言历史来看 差不多半年前就开始吐槽这个事儿，而且也从应聘职位的信息透露的信息中表明了你对现在工作的不满以及自身能力的认知很好，那不妨下次 Code Review 的时候让 Reviewers 直接讲清楚为何如此以及更优的逻辑是什么，虽然可能 Reviewers 跟你讲了你根本就没听进去，只顾着按照自己的想法吐槽，那对这种而言，1 年工作经验和 10 年又有什么区别呢 没有任何成长性

还有就是你在给部分回复里带有辱骂性的词汇就显得很 emmmmm 难评 ，如果你的思维一直停留在只写 CURD ，那也就一直这样儿了，言尽于此

[wzy44944]

@MrRongts 功能测试通过后还推翻，说明流程上可能有问题，我之前也遇到过频繁整体推翻的，后来次数太多了，大家就定了一个流程规范，其实也简单，就是
1. 开发前做一次设计评审，设计里尽可能把可能产生分歧的地方讲清楚，如果设计评审通过，代码评审就不能再推翻了，顶多是一些细枝末节的修改或者 bug 修改。
2. 代码评审可以和功能测试同步，就是尽可能早的提交评审，不需要成熟代码，这样尽早发现实现思路上的问题。
主要是降低沟通成本，减少沟通次数

[p2007]

建议举一些例子

[bugyaluwang]

review 从来不是「必须修改」的，说得服你就改，说不出理由就和他喷

[visper]

看了 12 楼，我感觉这就是闲得蛋疼。 大概是这种感觉: code review 是我的任务，如果不找点东西出来好像显示我没在工作一样。

[simo]

可以试试改变心态，代码改 10 遍，工资不少，照发是不？是的话，就当工地搬砖，一趟趟的，每次 20 块

[dog82]

我见过写得很漂亮的代码，刀劈斧削一样！
反观自己的写的是一坨屎！
所以得承认自己菜，有则改之，无则加勉……

[laminux29]

@MrRongts

链式处理当然不好，因为不利于调试。

从这个问题来看，难怪你容易被 Code Review 吐槽。平时写代码，要多考虑工程性。包括可读性、可调试行、模块化等等。

[MrRongts]

@yuanxing008 不经他人苦, 莫劝他人善。

[zidy]

我咋感觉上面那段 rust 是有一点问题呢😅，一定是我的问题😂

[lianhuayu420]

感觉现在 review 已经跑偏了, 纯纯变成了个人技术、知识储备的一个 battle 舞台，处处透漏着 "炫耀"，"我比你厉害" ，"我跟你不在一个 level"，"这你都不知道"等，技术素养跟文化有问题

[DefoliationM]

这位兄弟可能没看到前段时间 linus 因为一个函数喷 risc-v 的代码是垃圾，感觉和上面说的 “是眼高手低的伪程序员唯一能发挥的地方了”一样。

Linus Torvalds Calls Out RISC-V for "Garbage" Code

[Jack927]

@sfz97308 很棒，我们的团队里我也这样的。 有明确规定的格式、风格的， 还用了 AI 评审，不符合格式的就是得改。
我自己的代码也一样，要求其他人交叉评审。

每个项目首先都是工程，工程就应该有工程的标准。

尤其是现在，写代码都还用 ai 的情况下，必要性更大，有的不负责的人说不定就是 ai 生成之后自己试试有问题没有，生成的代码估计都没自己看过。

[MrRongts]

@lianhuayu420 你这个评价太到位了，说到心坎了，个人主义，专政，觉着自己无敌，我们组员一致的评价。review 这件事情，跟每个组员都闹个矛盾。

[540852101]

Code Review 更多的应该是讨论局部代码实现细节; 经常性全部推翻？？ 说明没有前期的代码设计评审，说明团队工作流程有问题。

[czhen]

@sfz97308 认同应该严格的 Code Review; 具体到 OP 的情况, 没有细节不好评价, 但 "经常性的都推翻" 这种感觉 Leader 的问题更大, 要么没有明确的规则规范, 要么没有写代码前的设计(技术方案)评审

[jettzhang]

不加班无所谓，他爱怎么就怎么样，出事了他背锅

[BlueBing]

我朋友公司的 cr ，是 cto+负责人一起过，很严格，不过他们是成熟的项目了，cr 力度不大。
我这边的话，属于初创，赶进度目前没有 pr ，cr 是负责人来，大的功能我会要求开会过，我也会参与。原则上，不影响功能的都先放行，不漂亮的地方，记录下来技术闲了之后安排优化。
op 这种情况我无法评价，但从管理的角度来看，规范是需要优于其他的。

[Tinyang]

换个人 review ？

[NerbraskaGuy]

如果不影响排期随他折腾呗，要是影响排期你事先说好 delay 了我不负责

[qingyingwan]

还在纠结 review ，说白了领导水平太菜了，不会设计架构只会扣细节。领导应该评审技术方案，或者亲自设计大项目的方案，定下流程和标准。代码 cr 这种细节都是打工人小兵来做就行。如果方案设计不合理，技术选型和风险讨论不到位，又没有流程和标准。就是代码玩出花来，对着完美代码规范扣出三室一厅，也解决不了项目的结构性缺陷。代码规范目的是为了方便合作，而不是整个项目围绕代码规范来舍本逐末。只要团队合作没问题，规范就不存在。

[OC0311]

code review 只做业务和容错上的评论，确保上线是没有 bug 的。至于代码的设计封装之类的 从来不会评论。因为临近上线或提测再改一坨不现实的。

[ZongjunLan]

@S1ahs3r 这不说的就是我前领导某道的管某某

[jciba5n4y6u]

@dlmy 小作坊，不说别人就不会笑话你


@MrRongts 看你写的是什么，库、底层框架都要严格，因为好多东西跑在你上面，生命周期很长。如果是应用，三天两头根据业务需求就变了，生命周期就个把月，那随便你写到飞起，只要业务逻辑跑得通，没有性能瓶颈和漏洞，随他去吧

[midsolo]

@jciba5n4y6u #88 公司不算小了，全球无人机品牌 TOP 20 强，管理层关注的是 "按照计划完成、按时交付给客户"，代码质量什么的往后放，用的还是 IBM 那一套 OOAD

[jciba5n4y6u]

@dlmy 那就是大作坊，像西贝那样的大作坊。

以前有个搞电子的同事，改行到互联网做产品经历，说他妈的中国老板，只会抄板子，换便宜配件，cost down 然后低价倾销，太他妈恶心了。现在想想，各行各业都是一样，都是赚快钱，赚到就收到口袋里，没人真正想做事业、做产品

没追求、没品位、没格局，行尸走肉

[mosesyou]

直接上 ai codereview,把团队规范啥的做进去

[midsolo]

@jciba5n4y6u #90 你说的没错，确实不太注重代码，公司注重的是 "产品交付"、"市场份额" 和 "品牌营销" 这些，方便在国内收割，最核心的那套代码跟算法，还是 10 年前国外团队写的。

[Nanosk]

@MrRongts #12 不是好正常嘛，还有傻鸟不知道 go 的 struct{}做 map value 的，硬是要你改

[encounter2017]

@MrRongts #12 不懂 rust, 不过这代码丢给 ai 分析，好像也看不过去。我认识的一个写 rust 的大佬说，乱用 unwrap 的都是在代码里拉屎

[ZiChun]

在某些时候 Code Review 还是很有必要的。比如我们之前招的 JAVA ，写代码的时候 for 循环里面调用 feign ，不 review 就等着生产事故吧。还有一些比如重点需求的事务、幂等、缓存等设计之类的也可以 Review 一下。但是 Code Review 不能太细，细到代码风格的程度就属于是没事找事了。

[vcbal]

我觉得楼上还是有些看出 op 本质的人的，op 自己看不清，还是老话，良言难劝，良药苦口

[MrRongts]

@encounter2017 我的代码贴的有点问题， 我思想是如果 key 没有值，就插入数组， 因为上面已经确定了肯定肯定有值了，unwrap 就是一个安全的操作，就好比其他语言的 obj!.cc 强行解析一个意思的东西。

let mut a = HashMap::new();
// 如果没有值就插入数组
if !a.contains_key("1") {
a.insert("1", vec![]);
}

a.get_mut("1").unwrap().push("1");

[MrRongts]

@encounter2017 你没有理解我的意思， 我不是反对好的写法我不认同，我反感点是，为什么组员用新的语法糖，review 时候你看不懂，你就让别人改，而你用的时候你却要大吹特吹，表现你的优越感。 角色调换一下位置如果我使用最直接的写法用 `a.entry("1").or_insert_with(Vec::new).push("1")` review 的那人又要说，这样写不容易看懂，换成上面的吧，这写法通用，每个语言都可以这么干。 这些语法糖只是举个例子，改一下一分钟的事情，说实话这根本不是我在意的点。
归根结底我讨厌的是个人主义，动不动就推翻别人的成果，还强行让别人承认你的方案就是比他的差。

[swananan]

op 的痛点，其实需要 review 标准化，大家对好的代码要有一致的理解，不能双标。你们应该拉一个标准，不断完善，每个人都互相学到东西。

[yanqing07]

@SignUpWithSolana #28 上 eslint 统一下呗。当修改某些文件时，vscode 自动改一下就好。有些规范就是应该交给工具