Code Review 经常性把别人的写的都推翻，让人按照他的想法来，这他妈的是什么个心理。 组里都特么都在吐槽，大环境下没人敢说不，太难了。以前担心被裁员，现在期望被裁员拿赔偿走。
74 条回复 • 2025-09-12 21:57:23 +08:00
 |
1
zsc8917zsc 1 天前
既然有 Code Review ，那写之前没定规范吗？
|
 |
2
vfs 1 天前
反过来讲： 会不会是自己代码写得不太行？
|
 |
3
DiamondYuan 1 天前
ai 时代这些都不是事，让 ai 写就行了。
请按照 xxx 要求修改代码。 修改后保持原有功能不变。 |
 |
5
S1ahs3r 1 天前  4
Code Review 已经是眼高手低的伪程序员唯一能发挥的地方了。
见过每次都对命名指手画脚的人么？（都符合命名规范） |
 |
6
MrRongts OP 1
@vfs 你费劲巴力的写了 2 天, 业务功能也完成了， 功能也测试过了。Code Review 说你这样写不好，有更好的方法，好你在根据他的想法重写，来回 Review, 为了一个他所谓“好” 折腾别人，无非是显自己很优越，我见过组里有人，为这种问题搞了好几周，人都麻了。
|
 |
10
bojackhorseman 1 天前
能跑就行了，功能实现了就行了。搁这写高考满分作文呢，留着家传吗？
|
 |
11
fj24911 1 天前
我认为 CodeView 作用有限。
将更多的时间放在前期设计和文档完善收益更大。 单元测试通过了就可以了，对结果负责，过程细节难以掌控。 AI 是个好帮手 |
|
12
MrRongts OP 有次写 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 链式处理方法，他说不好，给我的感觉就是只有他不知道，你就得改 |
 |
13
lambdaq 1 天前
你说下次一定啊。
下次写之前让他开个头。 |
 |
14
nananqujava 1 天前 1
现在还有什么弱不弱的, 我用 CC 写, 你咋挑刺?
|
 |
15
Huelse 1 天前
个人建议：听劝，他说什么都对，出问题也是推给他负责
|
 |
16
red13 1 天前
组员被 Code Review 折磨疯，说明 Leader 不具备管理能力
|
 |
17
janus77 1 天前
底层语言奇技淫巧多就会这样。写 java 会有这种苦恼？[狗头]
|
|
18
MrRongts OP 1
@bbao 很好奇你所谓强到底他妈的是啥。 都特么写一下 CRUD 能特么强到哪里去。 还能写出个花来？，还是发明了个什么设计模式，或者什么牛皮的算法。有些所谓的代码好，都是自我感觉良好罢了。
都是 7 ，8 多年程序员，功能都能实现，保证自己的东西不会出问题，对自己的东西负责。老是把自己想法强加于别人只会适得其反。 |
 |
21
oneisall8955 PRO 看得懂就不错了，语法糖的东西。。。
|
 |
22
qhd1988 1 天前
没有 eslint 规则之类的吗?定好规则,让机器 review 呗
|
 |
24
Seck 1 天前 1
兄弟：世界不是这样运行的，人家也许是面子上过得去就随口提了下，并不是真的要你如何改！
没有业务错误就可以，写代码记住，能运行就别动 世界运行方式很复杂，并不需要认真对待每一个 |
 |
25
cccssss 1 天前
兄弟，主动找他要个裁员大礼包走吧，你们不适合
|
 |
26
lizon 1 天前 via Android
0 总之不爽辞
1 Code Review 的人是谁, 为什么有权让你改? 1.1 组长? Leader? 不爽辞 1.2 组员? 完全可以拒绝或向上申请复议或者全组公开讨论 2 Code Review 应该在测试前之前就做完改完 3 整体重写的情况非常非常少, 是否是开发前的方案设计讨论就不充分 4 针对编码风格, 应该全组讨论制定统一的规范; 如果自己维护的业务在全周期由自己负责, 那你可以随便操, 反正也是鹅心下一个接盘侠; 如果是多人共同维护或者定期轮换, 你也不想维护被别人私自随意操烂的代码吧 |
 |
28
SignUpWithSolana 1 天前 via iPhone
之前我的上司不懂 js ，review 我的 pr 叫我把字符串的单引号改双引号，我没反驳，按照他说的改了
|
 |
29
2218675712 1 天前
ai 写代码，
ai review ， ai 根据 review 修复 上线后出 bug ，全滚蛋了 |
 |
30
dlmy 1 天前 1
这说明你们的工作量极度不饱和，不然哪有空折腾这个。
我司对我们的要求是：按时完成项目并按计划交付项目，代码的可靠性、可维护性和安全性被放在次要地位。 |
 |
31
Hanggi 1 天前
很简答，他给你 review 代码，不意味着对方的代码是正确答案，你再对他的代码进行 review 就行，更好的写法花点时间肯定能找到更好的，每次对方给你 review ，你就给你就给他 review 更好的写法，然后写个小文章，为什么要这么做，这样你自己能力也能提升，也能让对方知道自己 review 代码的局限性
|
 |
32
sorude 1 天前 1
最恶心的是严于他人，宽以自己的。 自己写的代码各种原因都能过，换成别人的代码化身为架构师的杂总
|
 |
34
profchaos 1 天前
@SignUpWithSolana 我觉得他很懂，双引号是对的
|
 |
35
JingXiao 1 天前
这种活最轻松啊，改就改呗，能让改说明项目也不是很赶啊，不然就让老大决定功能都 ok 了，再改来改去又延期风险。反正给时间不额外加班改这个都能接受
|
 |
36
FrankAdler 1 天前 via Android
手动实现还是用语法糖这种 review 的时候都要改，这还是太闲了，赶着上线的话锅要全部他一个人背？
正常的 code review 应该是侧重性能问题工程合理性啥的吧，比如 for 循环取数改为批量取，已有的逻辑不要重复实现，逻辑都写在 controller 层，漏掉一些异常处理这些 不然你就让他每种语言出个 lint ，别你写完了他想到哪你们改到哪 |
 |
37
irisdev 1 天前 via Android
我第一份工作跑路很大一部分原因就是一个比我早两年毕业的睿智 cr 老恶心我
|
 |
38
NotLongNil 1 天前
code review 有没有给出合理的理由？如果有，建议你心平气和的想想对方的理由是否合理。如果没有，就是纯粹的服从性测试，不敢辞就忍
|
 |
39
charlie21 1 天前
给钱了吗？拿钱了就改啊
|
 |
40
kristofer 1 天前
比较优秀的做法是：每一次 pr 都有 review ，而不是全都写完了，QA 都测完了才 review ，然后重写，这样会导致 QA 也要重新测试。
|
 |
41
dynastysea 1 天前
组员是你领导吗？是的话让你咋改就咋改，不是的话，难道你是怂 B 吗？你不改能把你吃了还是咋地
|
|
42
MrRongts OP @dynastysea 当然是领导啊，要组员不得怼死他。
|
|
44
dynastysea 1 天前
@MrRongts 那领导还说个毛线，要么辞职要么忍
|
 |
45
v2exe2v 1 天前
这就是某些人的执念，所以只能做做程序员
|
|
47
MrRongts OP @dlmy 忙的时候，MR 就堆在哪里，堆个 10 几 20 个一点不夸张，交付的时候经常出现合并冲突，然后丢代码，然后又让我们去改。
闲的时候，开始 review 了，一行一行的看, 写的跟他想法不一样，就要按他的想法来，重写，你还得拿笔记，想想心里都堵的慌。 |
|
48
MrRongts OP @dynastysea 裸辞太亏了，放开了，准备开怼了。混个 n+1
|
 |
49
dssxzuxc 1 天前
@profchaos #34 哪对了，这不就是代码风格不同，还能分个高下的。
那分号结尾对不对，尾随逗号对不对，箭头函数括号对不对，实验新三元组对不对。 只要有统一的代码风格强制限定，无论怎么配置我都认为对，反之无论怎么写都是错。 |
 |
50
yeelone 1 天前
我以前也是被 code review 折腾了一会儿，总要按照对方的方式来改。有时候就是口味不同而已。 并没有写法的高低。
后来，我们在写代码之前会大致把开发方案先写出来，一起过一下，再开始开始，这样的话，后面的 code review 只会看一眼代码的风格，代码的方向可以不用再有纠结的地方了。 |
 |
51
jhdxr 22 小时 55 分钟前
光看这个帖子：『 Code Review 经常性把别人的写的都推翻』，也很有可能是 reviewer 觉得自己带了一堆菜*还感觉无论如何都带不动那种
但看了你上个帖子里的例子，怎么说呢。 我觉得要是有**更**合理的理由（比如要支持上古的 IE ）其实 reviewer 的写法的确有道理，只是讨论可读性的话在这个例子上过于牵强，除非其他人都是上古程序员。。。 |
 |
52
hzj629206717 18 小时 49 分钟前
珍惜认真 Review 你代码的人吧。大多数人水平真的很一般可能自己还认识不到。
如果 Leader 的技术追求，技术审美，和技术水平都比你高，你就多学习学习。 |
 |
54
Tomfe 18 小时 28 分钟前 1
感觉有的人好像被 pua 习惯了 这种 leader 可不一定是有啥技术追求 单纯就是想搞一言堂 把组员当 AI 用 这种真就别忍着 你忍不住的 早点摆烂等着大礼包就得了
|
 |
55
SmiteChow 18 小时 9 分钟前
风格统一是必要的，风格由谁定，当然是你的领导。
|
 |
56
runzekk 18 小时 1 分钟前
你的 leader 也很无奈，不 review ，其他组的 leader 看到了不符合规范的代码，不显得自己也很菜么。review 吧，是人都讨厌别人找问题，重复工作，下面的人有意见，很难的。 所以我都是带着其他组员，开大会 review ，把火力分散出去，大家都觉得你写的有问题，那你大概率有问题了。
|
 |
57
guyeu 17 小时 44 分钟前
明显是流程的问题，code review 应该小步快跑，每个 commit 的内容少一些，反馈快一些，这样就不会改了一大堆全部被推翻。review 过了之后才会接受这个 merge ，才能进入功能测试流程呀，这样就不会出现产品上线等你这个 review 的修复了。
|
 |
58
mysunshinedreams 17 小时 27 分钟前
我在阿里进行 code review 的时候，committer 面对我提的意见会说：你提的建议我都理解，但是这个需求是 XX 老板点名今天晚上要上的，现在马上管控了，如果上不了这个锅你来背，之后我都是秒点通过。
|
 |
59
ElmerZhang 17 小时 12 分钟前
这说明你们在 code review 之前还应该再有一轮 design review 呀
|
 |
60
Akiya 14 小时 45 分钟前
到代码这一步才发现全部需要推翻重写的话，说明前面的流程完全没用
|
 |
61
Sfilata 14 小时 28 分钟前
要是我的话就无所谓，你让我咋改我咋改。又花不了几分钟，如果要重新实现就评估工期呗，这种爷说爷有理，婆说婆有理的事情怎么可能说得清楚。在团队中多人协作妥协是很正常的事情，如果这都要生气那去开源项目提 PR 几十个人 Review 你受的了？
|
|
62
Sfilata 14 小时 26 分钟前
@Sfilata 再说了，如果他能一视同仁的话也在另一层面上保证了代码风格和设计风格的一致性。只要保证功能不出大乱子也不是啥坏事。如果自己真有代码洁癖自己项目爱咋搞咋搞，不是自己的只要不是太离谱太明显的错误就按别人的来。
|
 |
63
sfz97308 14 小时 17 分钟前
我一直坚持提交符合团队规范的、命名合理、结构清晰的代码，坚持每个 PR 都只干一件事、并且在 PR 描述中详细写明修改背景、Before/After 对比截图、如何测试。
同时，我也是团队中 review PR 最多、对其他人的 PR 提 comment 最多的。好在因为我自己的代码和 PR 质量有目共睹，所以目前还算有点威信，大家看到我提的 comment ，如果合理也都会接受，如果有疑问会一起探讨。 当然，团队大了自然什么人都有，也有觉得我是“blocker”的，甚至私底下搞小动作，想要推动不允许与 feature 不直接相关的人 review 代码。他们会认为“这只是个名字，不重要”，“这种格式问题是小事儿“。他们的 repo 里，PR 几乎没有 comment ，都是直接 approve 了 -- 代码质量真的这么好吗？应该不是的，线上问题一点都不少。 老板们当然不会在意代码质量，所谓的可维护性，在他们眼里也只是明天才有可能出现的问题。他们更希望的是，今天提了需求，明天就能马上上线，严格的 code review 自然会让这个过程变慢。 但是开发者自己还是应该有点追求的吧！但是看到评论区的氛围，下面肯定要有人喷我了，就这样吧，现实还是得接受 |
 |
64
jciba5n4y6u 13 小时 52 分钟前
|
 |
65
yuanxing008 13 小时 47 分钟前
所以从你发言历史来看 差不多半年前就开始吐槽这个事儿，而且也从应聘职位的信息透露的信息中表明了你对现在工作的不满以及自身能力的认知很好，那不妨下次 Code Review 的时候让 Reviewers 直接讲清楚为何如此以及更优的逻辑是什么，虽然可能 Reviewers 跟你讲了你根本就没听进去，只顾着按照自己的想法吐槽，那对这种而言，1 年工作经验和 10 年又有什么区别呢 没有任何成长性
还有就是你在给部分回复里带有辱骂性的词汇就显得很 emmmmm 难评 ，如果你的思维一直停留在只写 CURD ，那也就一直这样儿了，言尽于此 |
 |
66
wzy44944 13 小时 22 分钟前
@MrRongts 功能测试通过后还推翻，说明流程上可能有问题，我之前也遇到过频繁整体推翻的，后来次数太多了，大家就定了一个流程规范，其实也简单，就是
1. 开发前做一次设计评审，设计里尽可能把可能产生分歧的地方讲清楚，如果设计评审通过，代码评审就不能再推翻了，顶多是一些细枝末节的修改或者 bug 修改。 2. 代码评审可以和功能测试同步，就是尽可能早的提交评审，不需要成熟代码，这样尽早发现实现思路上的问题。 主要是降低沟通成本，减少沟通次数 |
 |
67
parthenon2007 12 小时 54 分钟前
建议举一些例子
|
 |
68
bugyaluwang 12 小时 51 分钟前
review 从来不是「必须修改」的，说得服你就改，说不出理由就和他喷
|
 |
69
visper 12 小时 35 分钟前
看了 12 楼，我感觉这就是闲得蛋疼。 大概是这种感觉: code review 是我的任务，如果不找点东西出来好像显示我没在工作一样。
|
 |
70
simo 12 小时 29 分钟前
可以试试改变心态，代码改 10 遍，工资不少，照发是不？是的话，就当工地搬砖，一趟趟的，每次 20 块
|
 |
71
dog82 12 小时 23 分钟前
我见过写得很漂亮的代码，刀劈斧削一样！
反观自己的写的是一坨屎！ 所以得承认自己菜，有则改之，无则加勉…… |
 |
72
laminux29 12 小时 19 分钟前
|
|
73
MrRongts OP @yuanxing008 不经他人苦, 莫劝他人善。
|
 |
74
zidy 6 小时 33 分钟前
我咋感觉上面那段 rust 是有一点问题呢😅，一定是我的问题😂
|
Select Language