研发效率破局之道
葛俊
前 Facebook 内部工具团队 Tech Lead
34093 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 40 讲
开篇词 (1讲)
研发效率破局之道
15
15
1.0x
00:00/00:00
登录|注册

12 | 代码审查:哪种方式更适合我的团队?

机器检查:使用Phabricator进行代码审查之前,使用少量的团队集中审查
审查时机:将代码审查作为门禁的一部分,严格执行
审查范围:引入了设计时审查,对新人进行培训
审查方式:使用Phabricator的镜像方式进行代码审查,大量使用线下的异步审查流程
机器检查:使用Gerrit、Jenkins、SonarQube三个工具互相集成,自动化了较多的机器检查
审查时机:将代码审查作为门禁的一部分,严格执行
审查范围:在开始阶段,进行了几次多对一、面对面的代码全量审查
审查方式:工具辅助的线下一对一审查,偶尔使用团队审查
机器检查:使用GitHub的钩子运行各种Linter以及单元测试和一些集成测试
审查时机:没有强制使用代码入库前门禁检查,但将代码审查作为高优先级任务
审查范围:从开发第一个MVP开始,采用代码增量的一对一审查
审查方式:基于GitHub的线下异步审查,偶尔使用面对面审查
案例三:百人以上团队的代码审查实践
案例二:30人团队的代码审查实践
案例一:5个开发者组成的初创团队的代码审查实践
代码审查方式选择的三个成功案例

该思维导图由 AI 生成,仅供参考

你好,我是葛俊。今天,我们来聊聊都有哪些代码审查方式,以及哪种方式更适合你的团队。
国外互联网行业的很多效能标杆公司都非常重视代码审查(Code Review),比如 Facebook、Google 等就要求每一个提交都必须通过审查。
现在,国内的很多公司也在有意无意地引入代码审查:有的团队直接使用代码仓库管理工具提供的审查功能,比如 GitHub、GitLab 提供的 PR 审查;有的团队则使用专门的审查工具,比如 Phabricator、Gerrit;还有些团队采用面对面检查;甚至有少数公司,尝试使用结对编程的方式进行代码审查。
虽然国内公司在代码审查上做了不少尝试,也有一些公司做得比较好,比如我了解到七牛云就做得不错,但大多数国内公司还是对代码审查理解得不够深入,对审查方法的认识也不够全面,只能简单地去追随一些最佳实践。结果就是,有些团队的代码审查推行不下去,半途而废;有的则流于形式,花了时间却看不到效果。
那么,怎样才能做好代码审查呢?
我认为,做好代码审查的一个前提条件就是,要找到适合自己团队的方法。要做到这一点,你就要对代码审查有一个深入的了解,弄清楚常用方式及适用场景,然后才能做出正确选择。
所以,在今天这篇文章里,我首先会和你分享常用的代码审查方式及其适用场景,然后和你分享几个具体案例。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

代码审查是软件开发中至关重要的一环,本文介绍了不同的代码审查方式及其适用场景。文章首先对代码审查进行了分类,包括工具辅助的线下异步审查和面对面审查、一对一审查和团队审查、以及增量审查和全量审查。针对每种审查方式,详细讨论了其优缺点及适用场景,并分享了三个成功案例,展示了不同团队规模、引入代码审查的时机、适用的代码审查工具和方式。文章内容丰富,涵盖了代码审查的基本方式、特点及适用场景,对于软件开发团队的代码质量提升具有重要指导意义。总体来说,代码审查对团队产出质量、个人技术成长有很多好处,而根据不同维度可以选择合适的审查方式。文章还提到了设计时审查的作用,除了避免后期对代码的大规模调整外,还有助于顺利引入代码审查。文章内容丰富,对读者快速了解代码审查的概览具有重要参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《研发效率破局之道》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(17)

  • 最新
  • 精选
  • 技术修行者
    1. 你们团队使用了代码审查吗?具体使用了哪几种审查方式呢? 我们一般有设计审查和代码审查。设计审查需要全部人员参加,主要是统一大家的认识。代码审查采用离线代码审查的方式,每个team的team lead需要负责审查组员提交的所有代码,组员之间的互相审查比较少,因为组员的技术栈不太一样,有时不太容易给出比较专业的审查结果。这种方式的不好的地方1. 要求team lead有全栈经验,即使有些方面精通,但是要熟悉通用的原则,2. 比较占用team lead的精力,容易成为瓶颈。 2. 设计时检查除了可以避免后期对代码的大规模调整外,对顺利引入代码审查还有一些其他作用。 设计时审查很重要,它可以确保整个team对于设计的理解是一致的,而且设计审查不应该只包含技术人员,业务人员也鼓励参加,因为设计部分不会涉及太多技术系列,业务人员可以从业务角度给出一些评审意见。

    作者回复: 你们的审查做得挺好,点赞! 一个可以提高的是尽量多做相互审查,避免把审查任务集中在几个人身上。试一试多把权力和责任往下面分一分。

    2019-09-22
    8
  • 于小咸
    思考题2:设计时审查可以帮助审查者熟悉代码架构,提高审查者的审查效率。

    作者回复: 👍👍👍

    2019-09-18
    5
  • -W.LI-
    老师好!我怎么才能写出复合规范的代码呢,挺希望被review,又有点怕被review。核心代码,leader会进行设计时一对一review,提交前增量review。

    作者回复: 这要看你们团队的代码规范是什么样。 我推荐你跟leader了解清楚团队的规范,以及哪些方面需要特别注意。然后在代码审核的过程中不断进步。这样的话相信leader能够看到你学习的意愿,你的进步也会比较快。

    2019-10-02
    2
  • 吕哲
    还是一个很好的交流和学习设计模式及方法的机会😊

    作者回复: 👍👍👍

    2019-09-19
    2
  • 李双
    代码审查,很全面!非常赞同设计时审查!架构对了,细节容易调整!

    作者回复: 是的是的,门禁是一方面作用,早期讨论是另一方面作用。后者常被忽视

    2019-09-18
    2
  • li3huo
    linkin 的由作者发起的 code review 方式也很有特色,要求作者组织材料和会议,从而激励期责任感,提升审查效率

    作者回复: 有具体的链接参考吗?我只找到类似这样的:https://thenewstack.io/linkedin-code-review/,对过程的描述不多。

    2019-09-18
    2
    1
  • iMARS
    我们团队大概10个人左右,一般都是做预约面对面的代码审查,面对面是一种高带宽的沟通方式,对被评审人员的能力和习惯养成有很大帮助。对于敏态的项目,我们额外采用IDEA插件进行编码规约的控制,采用SonarQube进一步检查并根据优先级排期处理,并对严重问题通过Bug单进行修订。

    作者回复: ������������������

    2020-10-28
  • bidinggong
    绝大部分团队都适合引入工具进行异步的一对一审查。看来,我的公司主要要采用这个方式了

    作者回复: ������������

    2020-10-22
  • bidinggong
    做好代码审查的一个前提条件就是,要找到适合自己团队的方法。

    作者回复: ������������

    2020-10-22
  • GRD
    "入库后检查的另一个作用是,提高遗产代码的质量" 除非有对对遗产代码重构,或是进行全量审查才会碰到遗产代码 , 但这些与是否入库后检查无关 请问老师入库后检查如何具体提高遗产代码呢?谢谢

    作者回复: 这里因为代码已经入库,所以对它的审查是入库后代码审查的一种。 至于如何具体提高遗产代码,应该是根据需要有针对行的进行。最常见的情况是对某一部分进行重构提高质量或者是可维护性,那么就针对重点模块进行,首先确认有足够测试,然后逐步refactor,可以参考这本书https://www.amazon.com/Working-Effectively-Legacy-Code-EFFECT-ebook/dp/B005OYHF0A/ref=sr_1_1?dchild=1&keywords=Working+Effectively+with+Legacy+Code%3A&qid=1591626409&sr=8-1。

    2020-05-30
收起评论
显示
设置
留言
17
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部