大家在公司都是怎么组织 Code Review 的？高效吗？有效果吗？

• 資深大佬 : ZSeptember

  团队内的小 group 可以组织 review 。
  但我们一般是在 github flow 上执行的，向 INT 分支提交代码必须 2 人以上 review 。
  另外同 1 一样，有一个 common 的 review checklist，主要涉及到现有架构、业务模型和工作流上的需要注意的 review 点

• 資深大佬 : lovedebug

  最近发现 Code Review 实际上只能针对 Coding Rule 或者架构设计方面进行 Review，真正的实现细节，业务逻辑基本上是很难 Review 出问题的。某些逻辑错误不是真正需求实现者很难在短暂的 Review 中考虑到。最好还是 TDD，商量好接口以后指派两人分别开发 UT 和实现逻辑，Review 只是辅助。但这在很多开发资源紧张的情况下难以实现。

• 資深大佬 : Mithril

  github flow

• 資深大佬 : hantsy

  @Mithril 业务逻辑的正确依赖写测试，CI （ PR 分支跑 CI 自动化）。

• 資深大佬 : hantsy

  我们就是开个小会，大家过一下代码。其实代码看起来多，并没有多少，而且发现的大部分问题都是一些复用的问题，代码格式和习惯统一的问题。

• 資深大佬 : CBS

  我这边所有的开发都要在支线分支进行,完成了要提交 merge request,需要有高一级别的工程师(一般是组长,也可能是别的组的)来 review 代码.

  如果没有时间一行行看,也要确保你心里想的和他心里想的,和需求的要求是一致的.

  code review 是一个对人要求很高的工作,我以前公司也组织过,那时候是一个周期来一次 review,结果因为同事的水平实在太低,每次 review 都像是在教怎么写 Java,就没什么意思.

• 資深大佬 : SpencerCJH

  我认为 code review 更多的是 knowledge transfer 的作用，无论是业务 context 的传递，以及“优秀实践”的分享

• 資深大佬 : zclHIT

  gerrit

• 資深大佬 : VDimos

  @zclHIT 确实，看着是一组人，个个单兵作战

• 資深大佬 : server

  @hantsy 问题在于这个测试不能由同一个人写，不然基本都会变成对自己写好的业务逻辑进行测试。但是某些情况考虑不到的话就还是会漏掉。
  所以要么换人写，要么让 PM 去 Review 这些 UT 。但是前提是 PM 能看懂代码，而且有基本的逻辑思维能力。
  实际上很多 PM 的逻辑思维能力感人，很难考虑到自己的需求都有哪些极端情况。

• 資深大佬 : Mithril

  记得多年前在 HW 的代码 Review，更多时候是主讲的人，在讲代码包括逻辑、包括架构的实现过程中，讲的人发现代码的问题，别人发现的不多；提高效率的方法，主要是通过提前将修改前后的代码发出来，检视人提前了解代码的实现逻辑；

• 資深大佬 : twoconk

  upsource 很好用！
  但是实践上确实是个难题。感觉高质量的 review 基本也快把内容重新实现一遍了。。

• 資深大佬 : Arisky

  @Mithril 单元测试，集成测试必须是程序员自己写的。今天我还第一次听说测试要由别人写。

  一些大型公司有专门测试人员，写的测试只能是 UAT 阶段写的 Functional Test 代替手动测试功能，主要从需求角度进行黑盒测试，验证所有路径是否符合预期。

• 資深大佬 : hantsy

  @zclHIT 没错，Code review 更多的时候叫做 Peer Code Review，也可以当成 Pair Programming 的一种表现形式。相互 Code Review，主要是交流经验。国内程序员都是习惯了家长性的检查，认为 Code Review 永远是上级做的事，自己代码提交上去就不管了。

• 資深大佬 : hantsy

  任何一个 change 需要至少 2 个 review，approve 后才能合并

• 資深大佬 : ladypxy

  @server 以前我在公司上班的时候，经常听到的一个笑话，某个人呆了几年资历比较老的程序员在项目里，经常说一看什么代码风格就知道谁写的。我不得不说对于一个团队这是悲哀的。一个团队只应该有一种 Code Style，所有的 Bad Smell 应该在 Code Review 提出来干掉。有的人讲重构，讲代码质量说得头头是道，自己做的时候完全忘到一边了。

• 資深大佬 : hantsy

  @Arisky Jetbrains 的一套工具的确强大。TeamCity，Upsource，YourTrack, Space.

  对于小团队很合适, 不是说不大团队不行，主要它的 License 限制，小团队可以免费。

• 資深大佬 : hantsy

  所以，出个事故，开发这块代码的人请假或离职。你们打算重新读代码，然后一行一行的排查问题嘛？

• 資深大佬 : fewok

  大多数公司业务驱动，换句话说业务都写不完，CR 大多数都是走个形式，能大概过一眼，点个 approval 就不错了

• 資深大佬 : OakScript

  我总结了 code review 的两个凡是
  凡是能坚持半年以上的,项目通常都进行的不错.
  凡是能总结出文档的,通常项目都有牛人.
  反之则是
  凡是坚持不到半年的,项目通常都已经开始有臭味了
  凡是 code review 之后啥都没留下来的,最后就都不了了之了.

  code review 这个东西,有点像内功一样,平时你看不出来效果,还贼费时费力,当你真的遇到一个大坑的时候,才会觉得,code review 是多么的必要.但是呢,真到那个时候了,能坚持 code review 的人很多时候要么是愤而离开,要么就是开始随波逐流了.

• 資深大佬 : jianghu52

  @jianghu52 “能坚持 code review 的人很多时候要么是愤而离开,要么就是开始随波逐流了”, 老哥这句话扎心了，我就是那个愤而离开的

• 資深大佬 : Blaky

  @jianghu52 文档输出很重要，作为标准依据。
  人多了执行下来就困难，也就是为啥要 Review 了，还有新人还要培训等等。

• 主 資深大佬 : ha2vex

  @zclHIT 很同意，“优秀实践”，就是很多经验上的总结。

• 主 資深大佬 : ha2vex

  @jianghu52 总结出文档？这个怎么理解？

• 資深大佬 : wzzzx

  发布加个 code review 卡口。。
  然后定期挑选随机挑选变更进行 code review 会晒一下