CodeReview？烂了算了

[RiceMarch]

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

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

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

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

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

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

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

[hush3]

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

[ccyu220]

@hahadaxigua834 笑死

[konakona]

Code Review 的会议可以在一个迭代结束后、或一个项目接近完成时去组织会议，邀请参与人员。

会上，由每个人挑选一段自己认为需要改进的代码进行展示，给大家讲解这里的工作原理（做多 2 分钟），自己纠结的地方（ 2 分钟），请问大家有什么想法（ 10 分钟，如果大家没想法就自己讲一下心里其实还有那些做法，但是自己不确定）

[zw1one]

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

[luckyrayyy]

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

[Paaranoia]

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

[BeijingBaby]

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

[maichael]

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

[maichael]

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

[yaphets666]

团队氛围不行

[zaunist]

@wobuhuicode 太对了

[chenzesam]

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

[xiebiao]

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

### 1.自动化

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

TODO：搭建自动化工具

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

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

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

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

### 4.提供良性反馈

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

避免在审查时过多争论。

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

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

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

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

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

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

### 7.审查总结

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

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

[Cielsky]

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

[sgissb1]

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

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

[Cbdy]

LGTM 完事儿

[forgottencoast]

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

[hhjswf]

你这种像是团队分享