Code Review 经常性把别人的写的都推翻，让人按照他的想法来，这他妈的是什么个心理。 组里都特么都在吐槽，大环境下没人敢说不，太难了。以前担心被裁员，现在期望被裁员拿赔偿走。
50 条回复 • 2025-09-11 23:49:50 +08:00
 |
1
zsc8917zsc 11 小时 11 分钟前
既然有 Code Review ，那写之前没定规范吗？
|
 |
2
vfs 11 小时 4 分钟前
反过来讲： 会不会是自己代码写得不太行？
|
 |
3
DiamondYuan 11 小时 2 分钟前
ai 时代这些都不是事，让 ai 写就行了。
请按照 xxx 要求修改代码。 修改后保持原有功能不变。 |
 |
5
S1ahs3r 10 小时 56 分钟前  2
Code Review 已经是眼高手低的伪程序员唯一能发挥的地方了。
见过每次都对命名指手画脚的人么？（都符合命名规范） |
 |
6
MrRongts OP @vfs 你费劲巴力的写了 2 天, 业务功能也完成了， 功能也测试过了。Code Review 说你这样写不好，有更好的方法，好你在根据他的想法重写，来回 Review, 为了一个他所谓“好” 折腾别人，无非是显自己很优越，我见过组里有人，为这种问题搞了好几周，人都麻了。
|
 |
10
bojackhorseman 10 小时 51 分钟前
能跑就行了，功能实现了就行了。搁这写高考满分作文呢，留着家传吗？
|
 |
11
fj24911 10 小时 49 分钟前
我认为 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 10 小时 47 分钟前
你说下次一定啊。
下次写之前让他开个头。 |
 |
14
nananqujava 10 小时 44 分钟前
现在还有什么弱不弱的, 我用 CC 写, 你咋挑刺?
|
 |
15
Huelse 10 小时 43 分钟前
个人建议：听劝，他说什么都对，出问题也是推给他负责
|
 |
16
red13 10 小时 41 分钟前
组员被 Code Review 折磨疯，说明 Leader 不具备管理能力
|
 |
17
janus77 10 小时 34 分钟前
底层语言奇技淫巧多就会这样。写 java 会有这种苦恼？[狗头]
|
|
18
MrRongts OP @bbao 很好奇你所谓强到底他妈的是啥。 都特么写一下 CRUD 能特么强到哪里去。 还能写出个花来？，还是发明了个什么设计模式，或者什么牛皮的算法。有些所谓的代码好，都是自我感觉良好罢了。
都是 7 ，8 多年程序员，功能都能实现，保证自己的东西不会出问题，对自己的东西负责。老是把自己想法强加于别人只会适得其反。 |
 |
21
oneisall8955 PRO 看得懂就不错了，语法糖的东西。。。
|
 |
22
qhd1988 10 小时 19 分钟前
没有 eslint 规则之类的吗?定好规则,让机器 review 呗
|
 |
24
Seck 10 小时 7 分钟前
兄弟：世界不是这样运行的，人家也许是面子上过得去就随口提了下，并不是真的要你如何改！
没有业务错误就可以，写代码记住，能运行就别动 世界运行方式很复杂，并不需要认真对待每一个 |
 |
25
cccssss 10 小时 2 分钟前
兄弟，主动找他要个裁员大礼包走吧，你们不适合
|
 |
26
lizon 9 小时 58 分钟前 via Android
0 总之不爽辞
1 Code Review 的人是谁, 为什么有权让你改? 1.1 组长? Leader? 不爽辞 1.2 组员? 完全可以拒绝或向上申请复议或者全组公开讨论 2 Code Review 应该在测试前之前就做完改完 3 整体重写的情况非常非常少, 是否是开发前的方案设计讨论就不充分 4 针对编码风格, 应该全组讨论制定统一的规范; 如果自己维护的业务在全周期由自己负责, 那你可以随便操, 反正也是鹅心下一个接盘侠; 如果是多人共同维护或者定期轮换, 你也不想维护被别人私自随意操烂的代码吧 |
 |
28
SignUpWithSolana 9 小时 35 分钟前 via iPhone
之前我的上司不懂 js ，review 我的 pr 叫我把字符串的单引号改双引号，我没反驳，按照他说的改了
|
 |
29
2218675712 9 小时 5 分钟前
ai 写代码，
ai review ， ai 根据 review 修复 上线后出 bug ，全滚蛋了 |
 |
30
dlmy 8 小时 53 分钟前
这说明你们的工作量极度不饱和，不然哪有空折腾这个。
我司对我们的要求是：按时完成项目并按计划交付项目，代码的可靠性、可维护性和安全性被放在次要地位。 |
 |
31
Hanggi 8 小时 53 分钟前
很简答，他给你 review 代码，不意味着对方的代码是正确答案，你再对他的代码进行 review 就行，更好的写法花点时间肯定能找到更好的，每次对方给你 review ，你就给你就给他 review 更好的写法，然后写个小文章，为什么要这么做，这样你自己能力也能提升，也能让对方知道自己 review 代码的局限性
|
 |
32
sorude 8 小时 39 分钟前
最恶心的是严于他人，宽以自己的。 自己写的代码各种原因都能过，换成别人的代码化身为架构师的杂总
|
 |
34
profchaos 8 小时 11 分钟前
@SignUpWithSolana 我觉得他很懂，双引号是对的
|
 |
35
JingXiao 8 小时 7 分钟前
这种活最轻松啊，改就改呗，能让改说明项目也不是很赶啊，不然就让老大决定功能都 ok 了，再改来改去又延期风险。反正给时间不额外加班改这个都能接受
|
 |
36
FrankAdler 7 小时 57 分钟前 via Android
手动实现还是用语法糖这种 review 的时候都要改，这还是太闲了，赶着上线的话锅要全部他一个人背？
正常的 code review 应该是侧重性能问题工程合理性啥的吧，比如 for 循环取数改为批量取，已有的逻辑不要重复实现，逻辑都写在 controller 层，漏掉一些异常处理这些 不然你就让他每种语言出个 lint ，别你写完了他想到哪你们改到哪 |
 |
37
irisdev 5 小时 46 分钟前 via Android
我第一份工作跑路很大一部分原因就是一个比我早两年毕业的睿智 cr 老恶心我
|
 |
38
NotLongNil 5 小时 23 分钟前
code review 有没有给出合理的理由？如果有，建议你心平气和的想想对方的理由是否合理。如果没有，就是纯粹的服从性测试，不敢辞就忍
|
 |
39
charlie21 5 小时 20 分钟前
给钱了吗？拿钱了就改啊
|
 |
40
kristofer 5 小时 4 分钟前
比较优秀的做法是：每一次 pr 都有 review ，而不是全都写完了，QA 都测完了才 review ，然后重写，这样会导致 QA 也要重新测试。
|
 |
41
dynastysea 5 小时 0 分钟前
组员是你领导吗？是的话让你咋改就咋改，不是的话，难道你是怂 B 吗？你不改能把你吃了还是咋地
|
|
42
MrRongts OP @dynastysea 当然是领导啊，要组员不得怼死他。
|
|
44
dynastysea 4 小时 43 分钟前
@MrRongts 那领导还说个毛线，要么辞职要么忍
|
 |
45
v2exe2v 4 小时 43 分钟前
这就是某些人的执念，所以只能做做程序员
|
|
47
MrRongts OP @dlmy 忙的时候，MR 就堆在哪里，堆个 10 几 20 个一点不夸张，交付的时候经常出现合并冲突，然后丢代码，然后又让我们去改。
闲的时候，开始 review 了，一行一行的看, 写的跟他想法不一样，就要按他的想法来，重写，你还得拿笔记，想想心里都堵的慌。 |
|
48
MrRongts OP @dynastysea 裸辞太亏了，放开了，准备开怼了。混个 n+1
|
 |
49
dssxzuxc 4 小时 31 分钟前
@profchaos #34 哪对了，这不就是代码风格不同，还能分个高下的。
那分号结尾对不对，尾随逗号对不对，箭头函数括号对不对，实验新三元组对不对。 只要有统一的代码风格强制限定，无论怎么配置我都认为对，反之无论怎么写都是错。 |
 |
50
yeelone 4 小时 17 分钟前
我以前也是被 code review 折腾了一会儿，总要按照对方的方式来改。有时候就是口味不同而已。 并没有写法的高低。
后来，我们在写代码之前会大致把开发方案先写出来，一起过一下，再开始开始，这样的话，后面的 code review 只会看一眼代码的风格，代码的方向可以不用再有纠结的地方了。 |
Select Language