这是一个创建于 1001 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天下午 codereview ，我对着投屏讲我的代码，猛的一回头看发现我们组所有人都在玩手机，没有一个人听我讲，看着大家都低着头玩的时候，我顿了一下，声音小了一点点继续讲，没人看我，也没人听我讲，那一刻我的心里好难过好难过，哎。
codereview 已经成了形式，好想让大家批评批评我，和我产生点交流。
上次同事 A 对同事 B 的方案有些疑问，今天的 codereview ，B 就一直阴阳怪气在 A 。
大家就事论事不好吗，讨论技术就好了呀。
leader 更是编码和技术相关完全不参与，所有技术相关的会议都不参加，同事天天吐槽系统做得烂，线上问题一堆，能不烂么。
晚饭时，和隔壁组的同事一起吃饭，听他讲起他们组 codereview 时大家一起的思想的碰撞，团队里大牛的设计，他讲的眉飞色舞，我扒着嘴里的饭，好羡慕。
想好了，校招干满一年就跑路，刚来时的满腔热血，今天猛的一回头看到所有人都在玩手机真的好伤心。
38 条回复 • 2022-03-29 17:51:56 +08:00
 |
1
Rocketer 2022-03-24 22:21:54 +08:00 via iPhone  4
这不叫 code review 吧？听着更像讲课。
code review 是指所有人的代码在并入 master 分支之前都要经过其他人的审议通过。一般由高一级的程序员来审，高级之间互审。 |
 |
2
RiceMarch OP @Rocketer 确实不太像 code review...我可能没描述清楚，就是我来讲述自己的代码逻辑和编码细节，高一级的程序员们来审。
|
 |
3
t2jk4000 2022-03-24 22:32:47 +08:00
是这样的，烂就烂呗，想好怎么跑路就行了
|
 |
4
vivipure 2022-03-24 22:40:40 +08:00
code review 的原则就是不做任何批评。如果只是为了指责和抬杠的话，那的确就没啥意思了
|
 |
5
learningman 2022-03-24 22:50:50 +08:00 via Android
我经历过的 review 基本都是 mentor 来 review 。。。
|
 |
6
Shawlaw 2022-03-24 23:00:07 +08:00
整组开会的形式做 review 感觉效果不会好，责任不明确，而且对于 reviewers 来说上下文可能会有不少的缺失，沟通理解成本太高。
更适合的方式是指定熟悉模块更高一级的同事来做 reviewer ，但一般这样搞会出现整组就那么一两个人能做 review ，然后他们的工作就会“过载”，很可能看不过来，这点我作为 reviewee 和 reviewer 都经历过。 不过吧，当我在 B 君口中听到 A 君评价我给 A 君的代码 review 的过程和结果都很好时，内心真的很高兴。 |
 |
7
kop1989smurf 2022-03-24 23:00:36 +08:00 via iPad
听上去像是代码层面的逻辑分享会。
分享有必要，但是效率必然不高，而且并不会对生产力有过多的正面影响。 代码逻辑毕竟是很个人的东西。 你所认为的精妙设计，必然会有其掣肘。 不存在一个普世的，完全无懈可击的代码逻辑和设计模式。 而且只要不是南辕北辙式的逻辑错误，基本上运行效率大差不差。 毕竟别提 c# java ，连 JS 都是有编译器的，编译器会帮助程序员把语言化的逻辑思路转变为最大化性能的等效数据操作逻辑思路。 真正有效的，是保证公司代码风格规则的贯彻执行，以及保证代码可读性的 code review 。 写只有机器懂的代码逻辑不难。难的是写出初级程序员能懂的代码。 |
 |
8
hahadaxigua834 2022-03-24 23:04:55 +08:00 11
[how we write/review code in big tech companies]( )
|
 |
9
theprimone 2022-03-24 23:08:01 +08:00
溜就完事了~
|
 |
10
iyaozhen 2022-03-24 23:18:45 +08:00
没办法 跳槽吧
有没有兴趣来做测试开发，写代码没有版本压力 |
 |
11
wobuhuicode 2022-03-24 23:41:28 +08:00 via iPhone 2
商业化代码有什么所谓的 review 呢。不做这个需求的人永远无法明白，这一行烂代码就是在当时最能满足产品，测试，老板各方面需求下的产物。
|
 |
12
Macuilxochitl 2022-03-25 00:36:23 +08:00
@hahadaxigua834 LMAO
|
 |
13
Perry 2022-03-25 07:43:16 +08:00 via iPhone
你这个是在开会的情景下 code review 吗？这还能玩手机？这也太不尊重人了吧？
|
 |
14
rioshikelong121 2022-03-25 08:10:20 +08:00
@hahadaxigua834 真实
|
 |
15
missdeer 2022-03-25 09:20:09 +08:00
这种收益短期看不明显的事，从一开始需要从上往下硬推，后来形成固定的流程后，变成老人带新人，一直传承下去。所以我觉得你这种情况主要是领导有问题，要么别搞了，要么好好搞。
|
 |
16
tonymua 2022-03-25 09:24:07 +08:00
@wobuhuicode 确实
|
 |
17
zw1one 2022-03-25 09:36:19 +08:00
问题很明显了：“leader 更是编码和技术相关完全不参与，所有技术相关的会议都不参加”
这哪是 leader ，就是个监工 |
 |
18
MiniGhost 2022-03-25 09:41:12 +08:00 1
不要搞这种开会形式的 Code Review ，因为每个人对项目代码理解的程度大多都不同。
有可能一个新功能，就组内的 2 个同事比较熟悉，剩下的只知道个大概，那么在 Code Review 的时候，很容易就他们俩知道在聊什么，其他人根本听不懂，为了照顾其他同事大篇幅的讲上下文，也有可能一时半会儿消化理解不完。 最合适的是让你的 Reviewer 给你看代码，IM 里面把 PR/MR 丢过去，Reviewer 有空了帮你看一下，遇到问题在 PR/MR 中写评论。 如果觉得这个问题其他同事也需要注意，就把这个 PR/MR 丢在你们开发小群里，告知大家需要注意一下这里。 |
 |
19
JamesR 2022-03-25 10:30:35 +08:00
Code Review 收益最大的是本人，自己给自己 Code Review 最合适。
只要公司给时间 Code Review 我就很满意，我并不介意是否有人来弄，毕竟别人可能看不懂。 |
 |
21
hush3 2022-03-25 10:40:03 +08:00
确实 ，我也希望有人能指出我代码的问题，而且我也不会有任何不满。但问题是其他人可能会觉得这会使你感到不悦。同样的，我指出团队内其他人代码问题时也非常小心翼翼，注意措辞，生怕他觉得我针对他
|
 |
22
ccyu220 2022-03-25 10:49:11 +08:00
@hahadaxigua834 笑死
|
 |
23
konakona 2022-03-25 10:56:26 +08:00
Code Review 的会议可以在一个迭代结束后、或一个项目接近完成时去组织会议，邀请参与人员。
会上，由每个人挑选一段自己认为需要改进的代码进行展示，给大家讲解这里的工作原理（做多 2 分钟），自己纠结的地方（ 2 分钟），请问大家有什么想法（ 10 分钟，如果大家没想法就自己讲一下心里其实还有那些做法，但是自己不确定） |
 |
25
luckyrayyy 2022-03-25 11:16:45 +08:00
leader 的问题吧，我费尽心机改代码，还是天天被领导喷，都习惯了
|
 |
26
Paaranoia 2022-03-25 14:52:02 +08:00
为什么要抱着功利心 code review 呢？
假设我要去跑步，别人不关注，我就不跑了？ |
 |
27
BeijingBaby 2022-03-25 15:02:50 +08:00
其实大部分公司都和楼主的情况差不多，大家都是混口饭吃，对技术追求不高。
如果上层不重视，下层怎么可能改变呢？ 人到了群体后智商是会变低的。 |
 |
28
maichael 2022-03-25 15:06:19 +08:00
@Paaranoia #26 你这比喻是有问题的，code review 本身强调的就是 review ，都没人看了，没人 reiview 了，那还搞什么 review 。
|
|
29
maichael 2022-03-25 15:07:44 +08:00
这是很典型的团队技术氛围已经烂透了，和 Review 本身关系不大，压根没人在意代码写的怎么样，又怎么会有人去 Review 呢。
|
 |
30
yaphets666 2022-03-25 16:00:11 +08:00
团队氛围不行
|
 |
31
zaunist 2022-03-25 17:39:05 +08:00
@wobuhuicode 太对了
|
 |
32
chenzesam 2022-03-25 18:09:17 +08:00
深圳的吗？国际码：Y2hlbnplc2Ft ，招人~
|
 |
33
xiebiao 2022-03-25 18:13:59 +08:00 2
代码审查建议(code review)
------------------------- ### 1.自动化 常规检查自动化，比如可以借助[Spotbugs]( https://github.com/spotbugs/spotbugs)做代码静态扫描。 每次代码评审前先解决掉扫描结果中的 Error 。 TODO：搭建自动化工具 ### 2.代码审查之前确定审查内容 开发人员提前准备审查内容的上下文，每次审查内容不易太多，聚焦在被审查的核心内容上。 ### 3.每次代码审查时间不能超过 1 小时 聚焦在被审查的代码本身上，防止偏离主题，精力疲劳。 ### 4.提供良性反馈 如果开发人员的设计思路与审查人员有很大分歧，应该以开发人员思路为主，是否采纳审查人员提供的思路，由开发人员决定。 避免在审查时过多争论。 **推翻设计思路，应该发生在项目详细设计阶段，而不是代码审查阶段。** ### 5.问题归类，避免陷入争论 有时候我们在说服对方的时候，应该提供一些可以依赖的依据，例如：为何需要使用某种算法， 解决这个问题的原则是什么，计算机领域的很多问题是有理论支撑的，在解释为什么要这么做，最好能提供依赖原则。 ### 6.做好审查会议纪要 对于需要在审查后修改的地方，有明确的会议纪要，在后续审查时，方便审查人员回顾。 TODO：每次代码审查会议纪要通过邮件发送到组内 ### 7.审查总结 代码审查是大家经验交流的一个契机，也是相互学习的时候，开发人员可以总结一些审查中的心得。 - 是否有更好的命名方式？ - 是否学习到了新的设计模式？ - 是否有更好的代码组织方式？ - 是否学习到了新的工具？ |
 |
34
Cielsky 2022-03-25 18:21:21 +08:00 via Android
这不就是一个流于形式的分享大会吗？
就算不流于形式其实效率也是很低的 |
 |
35
sgissb1 2022-03-25 18:28:34 +08:00
codereview?这个东西是一个很神奇的东西，搞的好，可以让代码质量很高，大家工作效率很高。
搞的不好就是一个负担。 但事实上 codereview 最佳实践目前还没有，大多数是经验性的探讨。毕竟这是和人打交道比较多。 这玩意吧，代码不是太烂，就没必要搞，因为大家都不同程度的略反感。 |
 |
36
Cbdy 2022-03-25 19:03:34 +08:00
LGTM 完事儿
|
 |
37
forgottencoast 2022-03-26 16:53:56 +08:00
我觉得这种形式不可取，正如前面有人提到的，不熟悉的人感觉浪费自己的时间。
应该采用现代化的 Code Review 工具，就邀请相关人员。 组员 review 功能，资深 /架构师这些 review 架构方面的设计等，不同的人关注点不同，大家都同意了就过了。 |
 |
38
hhjswf 2022-03-29 17:51:56 +08:00
你这种像是团队分享
|
Select Language