因为小组内所有代码需要通过 mr 后才会合到 master ，我会参与到 code review 并给予一些修改建议，但是有时候我提的一些建议其他小伙伴好像并不能做出针对性的调整。我理解这主要是认知的不同导致的，即使我说出了自己的看法，但是对方并不能 get 到。
那么 review 代码时候，我是否还要继续无所保留的给出自己的意见呢，我要如何平衡这个落差感呢？
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 1415 days ago, the information mentioned may be changed or developed.
 |
yikyoDec 22, 2022 via iPhone
1
找个第三者评估
|
 |
optionalDec 22, 2022 via iPhone
2
CR 前是需要统一思想的，CR 我看起来是比单元测试更重要的东西
|
 |
tt67wqDec 22, 2022
3
提还是要提，改不改就不归你管了
|
 |
4
当这件事情已经失去本质意义，但组内还要求必须走 mr 的流程，那就做个样子走完流程就行了，不要做一些费力不讨好的事情。
|
2 |
fkdogDec 22, 2022
5
如果组里没有这样的氛围的话，走个流程就完事了。
代码风格一类的不是自己的不要多管，大部分人都不喜欢别人教自己做事。 如果是有明显 bug 的话，你可以用委婉的方式提一下，比如“这里我刚 debug 下好像有点问题，你帮忙看下我这样是不是正常的。blah blah” |
 |
god7dDec 22, 2022 via iPhone
6
与其费时劳力 cr ，不如招聘的时候就把好关
|
 |
codexianDec 22, 2022
7
看下来楼主是对技术有追求的，其他小伙伴是混口饭吃的（绝大多数人的状态）
但后续怎么做，还是看楼主自己，但就我主观而言，改变别人的认知是一件非常吃力不讨好的事情 |
 |
lazyfighterDec 23, 2022
9
提是你的事情 不改是他的事情， 能力不同，有时候就是对牛弹琴， 还觉得你挑刺
|
 |
marco330Dec 23, 2022
10
同感。现在我做 cr ，只要没有逻辑问题或者和我预期没有太大的偏差，我都忽略了。每个人都有自己的代码风格。
|
 |
11
kubernetes 社区有一句话可以借鉴一下：
教别人怎么做，而不是告诉他你改做什么。 如果别人 get 不到你的 idea ，就直接给他方案，show code ，过几次水平就拉齐了 |
 |
braderDec 23, 2022
12
这方面几年下来我也经历了很多，现在我期盼我的合作伙伴就一个要求，代码格式符合基本要求就行了，不要那种缩进没有、缩进乱、注释乱，就 OK 了，你逻辑怎么写，一个方法多长，怎么封装，甚至你自认为没必要写注释的，这些我都不管你。
怀着这个心态，我这几年不知道多省心 |
 |
MeltdownDec 23, 2022
13
给出意见就好了，改不改是他自己的事
|
 |
LeviathannDec 23, 2022
14
0. 别瞎改我代码
1. 别太明目张胆的堆屎 2. 逻辑对不对是测试的事，只看代码的写法 |
|
LeviathannDec 23, 2022
15
另外碰到代码写法的问题，我会自己写一遍看看是不是能按我想的那样改，写完贴上去一般他都没话说了
|
 |
cnin0770Dec 23, 2022 via iPhone
16
我 review 的时候：能不改别人的 code 就不改 除非功能性的 性能上的 因为很多时候改的冲动都是“看不惯他这么写”而已 再三思考 是不是一定改 改了比不改好
|
 |
IvanLi127Dec 23, 2022 via Android
17
没用，除非组员憧憬你，否则人家可能还觉得你给的意见是扯淡呢。
|
 |
mysunshinedreamsDec 24, 2022
18
"我知道我这块代码有问题，但是今天老板要求必须要发版，你让我改代码是需要时间的，耽误了发版是你来承担责任吗？"
|
 |
lixiang2017Dec 24, 2022 via Android
19
目前所在公司 code review 极其严格。给出的 comments 基本都要修改，
|
|
lixiang2017Dec 24, 2022 via Android
20
不少时候要修改好多次才能通过，最后才让合进去。某些不想改的地方，除非自己能说出合理的理由
|
Select Language