CodeReview？烂了算了

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

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

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

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

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

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

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

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

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

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

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

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

[how we write/review code in big tech companies]( )

溜就完事了~

没办法 跳槽吧

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

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

@hahadaxigua834 LMAO

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

@hahadaxigua834 真实

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

@wobuhuicode 确实

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

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

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


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

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

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

确实 ，我也希望有人能指出我代码的问题，而且我也不会有任何不满。但问题是其他人可能会觉得这会使你感到不悦。同样的，我指出团队内其他人代码问题时也非常小心翼翼，注意措辞，生怕他觉得我针对他

@hahadaxigua834 笑死

@JamesR 哈哈 以前公司的 code review 都是下班后做

leader 的问题吧，我费尽心机改代码，还是天天被领导喷，都习惯了

为什么要抱着功利心 code review 呢？
假设我要去跑步，别人不关注，我就不跑了？

其实大部分公司都和楼主的情况差不多，大家都是混口饭吃，对技术追求不高。
如果上层不重视，下层怎么可能改变呢？
人到了群体后智商是会变低的。

@Paaranoia #26 你这比喻是有问题的，code review 本身强调的就是 review ，都没人看了，没人 reiview 了，那还搞什么 review 。

这是很典型的团队技术氛围已经烂透了，和 Review 本身关系不大，压根没人在意代码写的怎么样，又怎么会有人去 Review 呢。

团队氛围不行

@wobuhuicode 太对了

深圳的吗？国际码：Y2hlbnplc2Ft ，招人~

代码审查建议(code review)
-------------------------

### 1.自动化

常规检查自动化，比如可以借助[Spotbugs]( https://github.com/spotbugs/spotbugs)做代码静态扫描。
每次代码评审前先解决掉扫描结果中的 Error 。

TODO：搭建自动化工具

### 2.代码审查之前确定审查内容

开发人员提前准备审查内容的上下文，每次审查内容不易太多，聚焦在被审查的核心内容上。

### 3.每次代码审查时间不能超过 1 小时

聚焦在被审查的代码本身上，防止偏离主题，精力疲劳。

### 4.提供良性反馈

如果开发人员的设计思路与审查人员有很大分歧，应该以开发人员思路为主，是否采纳审查人员提供的思路，由开发人员决定。

避免在审查时过多争论。

**推翻设计思路，应该发生在项目详细设计阶段，而不是代码审查阶段。**

### 5.问题归类，避免陷入争论

有时候我们在说服对方的时候，应该提供一些可以依赖的依据，例如：为何需要使用某种算法，
解决这个问题的原则是什么，计算机领域的很多问题是有理论支撑的，在解释为什么要这么做，最好能提供依赖原则。

### 6.做好审查会议纪要

对于需要在审查后修改的地方，有明确的会议纪要，在后续审查时，方便审查人员回顾。

TODO：每次代码审查会议纪要通过邮件发送到组内

### 7.审查总结

代码审查是大家经验交流的一个契机，也是相互学习的时候，开发人员可以总结一些审查中的心得。

- 是否有更好的命名方式？
- 是否学习到了新的设计模式？
- 是否有更好的代码组织方式？
- 是否学习到了新的工具？

这不就是一个流于形式的分享大会吗？
就算不流于形式其实效率也是很低的

codereview?这个东西是一个很神奇的东西，搞的好，可以让代码质量很高，大家工作效率很高。
搞的不好就是一个负担。

但事实上 codereview 最佳实践目前还没有，大多数是经验性的探讨。毕竟这是和人打交道比较多。
这玩意吧，代码不是太烂，就没必要搞，因为大家都不同程度的略反感。

LGTM 完事儿

我觉得这种形式不可取，正如前面有人提到的，不熟悉的人感觉浪费自己的时间。
应该采用现代化的 Code Review 工具，就邀请相关人员。
组员 review 功能，资深 /架构师这些 review 架构方面的设计等，不同的人关注点不同，大家都同意了就过了。

你这种像是团队分享