CodeReview？烂了算了

[RiceMarch]

今天下午 codereview ，我对着投屏讲我的代码，猛的一回头看发现我们组所有人都在玩手机，没有一个人听我讲，看着大家都低着头玩的时候，我顿了一下，声音小了一点点继续讲，没人看我，也没人听我讲，那一刻我的心里好难过好难过，哎。

codereview 已经成了形式，好想让大家批评批评我，和我产生点交流。

上次同事 A 对同事 B 的方案有些疑问，今天的 codereview ，B 就一直阴阳怪气在 A 。

大家就事论事不好吗，讨论技术就好了呀。

leader 更是编码和技术相关完全不参与，所有技术相关的会议都不参加，同事天天吐槽系统做得烂，线上问题一堆，能不烂么。

晚饭时，和隔壁组的同事一起吃饭，听他讲起他们组 codereview 时大家一起的思想的碰撞，团队里大牛的设计，他讲的眉飞色舞，我扒着嘴里的饭，好羡慕。

想好了，校招干满一年就跑路，刚来时的满腔热血，今天猛的一回头看到所有人都在玩手机真的好伤心。

[Rocketer]

这不叫 code review 吧？听着更像讲课。

code review 是指所有人的代码在并入 master 分支之前都要经过其他人的审议通过。一般由高一级的程序员来审，高级之间互审。

[RiceMarch]

@Rocketer 确实不太像 code review...我可能没描述清楚，就是我来讲述自己的代码逻辑和编码细节，高一级的程序员们来审。

[t2jk4000]

是这样的，烂就烂呗，想好怎么跑路就行了

[vivipure]

code review 的原则就是不做任何批评。如果只是为了指责和抬杠的话，那的确就没啥意思了

[learningman]

我经历过的 review 基本都是 mentor 来 review 。。。

[Shawlaw]

整组开会的形式做 review 感觉效果不会好，责任不明确，而且对于 reviewers 来说上下文可能会有不少的缺失，沟通理解成本太高。
更适合的方式是指定熟悉模块更高一级的同事来做 reviewer ，但一般这样搞会出现整组就那么一两个人能做 review ，然后他们的工作就会“过载”，很可能看不过来，这点我作为 reviewee 和 reviewer 都经历过。

不过吧，当我在 B 君口中听到 A 君评价我给 A 君的代码 review 的过程和结果都很好时，内心真的很高兴。

[kop1989smurf]

听上去像是代码层面的逻辑分享会。
分享有必要，但是效率必然不高，而且并不会对生产力有过多的正面影响。

代码逻辑毕竟是很个人的东西。
你所认为的精妙设计，必然会有其掣肘。
不存在一个普世的，完全无懈可击的代码逻辑和设计模式。

而且只要不是南辕北辙式的逻辑错误，基本上运行效率大差不差。
毕竟别提 c# java ，连 JS 都是有编译器的，编译器会帮助程序员把语言化的逻辑思路转变为最大化性能的等效数据操作逻辑思路。

真正有效的，是保证公司代码风格规则的贯彻执行，以及保证代码可读性的 code review 。
写只有机器懂的代码逻辑不难。难的是写出初级程序员能懂的代码。

[hahadaxigua834]

[how we write/review code in big tech companies]( <amp-youtube data-videoid="rR4n-0KYeKQ" layout="responsive" width="480" height="270"></amp-youtube>)

[theprimone]

溜就完事了~

[iyaozhen]

没办法 跳槽吧

有没有兴趣来做测试开发，写代码没有版本压力

[wobuhuicode]

商业化代码有什么所谓的 review 呢。不做这个需求的人永远无法明白，这一行烂代码就是在当时最能满足产品，测试，老板各方面需求下的产物。

[Macuilxochitl]

@hahadaxigua834 LMAO

[Perry]

你这个是在开会的情景下 code review 吗？这还能玩手机？这也太不尊重人了吧？

[rioshikelong121]

@hahadaxigua834 真实

[missdeer]

这种收益短期看不明显的事，从一开始需要从上往下硬推，后来形成固定的流程后，变成老人带新人，一直传承下去。所以我觉得你这种情况主要是领导有问题，要么别搞了，要么好好搞。

[tonymua]

@wobuhuicode 确实

[zw1one]

问题很明显了：“leader 更是编码和技术相关完全不参与，所有技术相关的会议都不参加”
这哪是 leader ，就是个监工

[MiniGhost]

不要搞这种开会形式的 Code Review ，因为每个人对项目代码理解的程度大多都不同。

有可能一个新功能，就组内的 2 个同事比较熟悉，剩下的只知道个大概，那么在 Code Review 的时候，很容易就他们俩知道在聊什么，其他人根本听不懂，为了照顾其他同事大篇幅的讲上下文，也有可能一时半会儿消化理解不完。


最合适的是让你的 Reviewer 给你看代码，IM 里面把 PR/MR 丢过去，Reviewer 有空了帮你看一下，遇到问题在 PR/MR 中写评论。
如果觉得这个问题其他同事也需要注意，就把这个 PR/MR 丢在你们开发小群里，告知大家需要注意一下这里。

[JamesR]

Code Review 收益最大的是本人，自己给自己 Code Review 最合适。
只要公司给时间 Code Review 我就很满意，我并不介意是否有人来弄，毕竟别人可能看不懂。

[JamesR]

@zw1one #17 可能这 Leader 是个销售，只是用来能带来项目的。