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

组织?
一般就是合并代码的时候 Review
如果大家都认真的话,确实很耗时间,有时候会 block,不过整体对团队,对自己,对项目都是有好处的
我们现在的做法是,先提交模块 interface 定义,大家 review,定好接口后,简单方法的具体实现不会 reivew 的很细
可以定个 reivew checklist,定好 reivew 需要关注哪些方面,不然 review 的时候很容易发散,就浪费时间了

相关文章

24 thoughts on “大家在公司都是怎么组织 Code Review 的?高效吗?有效果吗?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

发表评论

电子邮件地址不会被公开。 必填项已用*标注