研发效率破局之道
葛俊
前Facebook内部工具团队Tech Lead
立即订阅
3343 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要关注研发效能?
免费
研发效能综述 (3讲)
01 | 效能模型:如何系统地理解研发效能?
02 | 效能度量:效果不好甚至有副作用,怎么回事?
03 | 效能度量:如何选对指标与方法,真正提升效能?
研发流程 (7讲)
04 | 流程优化:怎样才能让敏捷、精益真正为我所用?
05 | 代码入库前:Facebook如何让开发人员聚焦于开发?
06 | 代码入库到产品上线:Facebook如何使用CI/CD满足业务要求?
07 | 分支管理:Facebook的策略,适合我的团队吗?
08 | DevOps、SRE的共性:应用全栈思路打通开发和运维
09 | 信息流通:让团队高效协同,让产品准确击中目标
10 | 答疑篇:反对996并不是反对奋斗
工程方法 (10讲)
11 | 研发环境:Facebook怎样让开发人员不再操心环境?
12 | 代码审查:哪种方式更适合我的团队?
13 | 代码审查:学习Facebook真正发挥代码审查的提效作用
14 | 质量与速度的均衡:让“唯快不破”快得更持久
15 | 开源:从Phabricator的开源历程看开源利弊
16 | 高效上云:如何用云计算来提高效能?
17 | 测试左移:测试如何应对新的开发模式?
18 | 蓝绿红黑灰度发布:这些五颜六色的发布到底怎么用?
19 | 不再掉队,研发流程、工程方法趋势解读和展望
20 | 答疑篇:如何平衡短期收益和长期收益?
个人效能 (11讲)
21 | 高效工作:Facebook的10x程序员效率心法
22 | 深度工作:聚焦最有价值的事儿
23 | 效率工具:选对用对才能事半功倍
特别放送 | 每个开发人员都应该学一些VIM
24 | VIM:如何高性价比地学习VIM的实用技巧?
25 | 玩转Git:五种提高代码提交原子性的基本操作
26 | Facebook怎样实现代码提交的原子性?
27 | 命令行:不只是酷,更重要的是能提高个人效能
28 | 从工作场景出发,寻找炫酷且有效的命令行工具
29 | 1+1>2,灵活的工具组合及环境让你的工作效率翻倍
30 | 答疑篇:关于价值导向和沟通
管理和文化 (6讲)
31 | 业务目标和技术目标两手抓:怎样打造高效团队?
32 | 从Netflix公开的著名PPT谈硅谷公司文化
33 | Facebook企业文化:工程师文化是创造力引擎
34 | Facebook工程师文化实践三大支柱之一做感兴趣的事
35 | Facebook工程师文化实践三大支柱之二拥有信息和权限
36 | Facebook工程师文化实践三大支柱之三绩效调节
结束语 (1讲)
结束语 | 超越昨天的自己,享受成长的快乐
研发效率破局之道
登录|注册

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

葛俊 2019-09-18
你好,我是葛俊。今天,我们来聊聊都有哪些代码审查方式,以及哪种方式更适合你的团队。
国外互联网行业的很多效能标杆公司都非常重视代码审查(Code Review),比如 Facebook、Google 等就要求每一个提交都必须通过审查。
现在,国内的很多公司也在有意无意地引入代码审查:有的团队直接使用代码仓库管理工具提供的审查功能,比如 GitHub、GitLab 提供的 PR 审查;有的团队则使用专门的审查工具,比如 Phabricator、Gerrit;还有些团队采用面对面检查;甚至有少数公司,尝试使用结对编程的方式进行代码审查。
虽然国内公司在代码审查上做了不少尝试,也有一些公司做得比较好,比如我了解到七牛云就做得不错,但大多数国内公司还是对代码审查理解得不够深入,对审查方法的认识也不够全面,只能简单地去追随一些最佳实践。结果就是,有些团队的代码审查推行不下去,半途而废;有的则流于形式,花了时间却看不到效果。
那么,怎样才能做好代码审查呢?
我认为,做好代码审查的一个前提条件就是,要找到适合自己团队的方法。要做到这一点,你就要对代码审查有一个深入的了解,弄清楚常用方式及适用场景,然后才能做出正确选择。
所以,在今天这篇文章里,我首先会和你分享常用的代码审查方式及其适用场景,然后和你分享几个具体案例。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • 日拱一卒
    1. 你们团队使用了代码审查吗?具体使用了哪几种审查方式呢?
    我们一般有设计审查和代码审查。设计审查需要全部人员参加,主要是统一大家的认识。代码审查采用离线代码审查的方式,每个team的team lead需要负责审查组员提交的所有代码,组员之间的互相审查比较少,因为组员的技术栈不太一样,有时不太容易给出比较专业的审查结果。这种方式的不好的地方1. 要求team lead有全栈经验,即使有些方面精通,但是要熟悉通用的原则,2. 比较占用team lead的精力,容易成为瓶颈。

    2. 设计时检查除了可以避免后期对代码的大规模调整外,对顺利引入代码审查还有一些其他作用。
    设计时审查很重要,它可以确保整个team对于设计的理解是一致的,而且设计审查不应该只包含技术人员,业务人员也鼓励参加,因为设计部分不会涉及太多技术系列,业务人员可以从业务角度给出一些评审意见。

    作者回复: 你们的审查做得挺好,点赞!

    一个可以提高的是尽量多做相互审查,避免把审查任务集中在几个人身上。试一试多把权力和责任往下面分一分。

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

    作者回复: 👍👍👍

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

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

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

    作者回复: 这要看你们团队的代码规范是什么样。

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

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

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

    2019-09-18
    1
    1
  • Luuuuke 。
    拆分为多次原子性提交,可能会导致TL需要抽出很多次空余时间来审查代码,会影响TL的工作效率吧?这个如何平衡呢?

    作者回复: 首先,代码审查最好是交叉审查,也就是团队成员互相审查,这样TL不会成为瓶颈。

    第二,这样做实际上是会提高代码审查效率的。因为每一个提交都更加清晰。如果一大团代码审查,要么审查不清楚。如果要深查清楚,花的时间肯定比这一团代码被原子化后的多。

    2019-11-06
  • Clay
    Phabricator配置和使用都有些复杂,像upsource这种,必须要推送到远程仓库的review感觉怎么做都有些别扭呢。比如我每一个feature可能有10个commit,我希望每次commit都审查后提交,用merge request审查比较麻烦呢

    作者回复: > 用merge request审查比较麻烦呢

    这个能详细解释一下吗?

    2019-10-29
    1
  • 白了少年头
    刚好最近跟公司提到了引入代码审查,随后就看到了这篇文章,真想把文章发给领导看看!

    作者回复: 那就发啊,还在犹豫什么!哈哈 :)

    2019-10-12
  • 二狗
    之前代码审查开成了批斗大会,有不符合规范的还有处罚措施

    作者回复: 后来效果怎么样?有继续推行吗?

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

    作者回复: 👍👍👍

    2019-09-19
收起评论
10
返回
顶部