研发效率破局之道
葛俊
前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讲)
结束语 | 超越昨天的自己,享受成长的快乐
研发效率破局之道
登录|注册

13 | 代码审查:学习Facebook真正发挥代码审查的提效作用

葛俊 2019-09-20
你好,我是葛俊。今天我们来聊聊代码审查的落地。
在上一篇文章中,我和你详细讨论了代码审查的作用,也给出了选择适合自己团队审查方式的建议。但是,仅仅知道要做什么还不够,更重要的是落地。我见到很多国内公司也在尝试使用代码审查,但是效果很不好,往往流于形式,最常听到的一个负面反馈就是“代码审查浪费时间”。
代码审查的成功推行的确不是一件容易的事。今天,我们就一起尝试来解决这个问题。我会从三个方面给出一些建议:
第一,在团队内引入代码审查的步骤和方法;
第二,成功推进代码审查的关键操作;
第三,持续做好代码审查的重要原则。
今天的文章较长,我们现在就进入第一个部分,

引入代码审查的步骤和方法

从我的经验来看,要成功引入代码审查,首先要在团队内达成一些重要的共识,然后选择试点团队实行,最后选择合适的工具和流程。

1. 代码审查应该计入工作量

代码审查需要时间,这听起来好像是废话,但很多团队在引入代码审查时,都没有为它预留时间。结果是大家没有时间做审查,效果自然也就不好。而效果不好又导致代码审查得不到管理者重视,开发人员更不可能将代码审查放到自己的工作计划中。于是,形成恶性循环,代码审查要么被逐渐废弃,要么流于形式。
之前在 Facebook 的时候,我们预估工作量的时候就会考虑代码审查的时间。比如,我平均每天会预留 1~2 个小时用于代码审查,大概占写代码总时间的 1/5。同时,代码审查的情况会作为绩效考评的一个重要指标。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(7)

  • john_zhang
    我们推行过一段时间代码审查,因为三五个人,所以采用的是团体审查,每天半个小时左右,可惜后来开发进度赶,慢慢就没做了,现在开发同事总是以进度赶为由,不太认同代码审查,怎么破?

    作者回复: 从点赞的数量来看,大家对这个问题是比较感兴趣的。我建议以下几个办法:

    1. 团队统一思想,代码审查是有效工作的一部分,应该计算到工作量里面
    2. 减少团体审查,选择更多使用工具进行1对1的审查。前者很难做到效率高。应该只是针对一些重点的提交采用这种方式。
    3. 培训团队,统一认识,让大家了解到代码审查的长期收益,让大家不能不能只看到当前的开发进度这个短期收益,还要考虑代码可维护性以及后续添加新功能的速度这些长期收益。甚至可以坚持推动代码审查这个操作作为团队的制度。

    后面的答疑文章我会作进一步的讨论。

    2019-09-20
    1
    11
  • Just for fun
    老师您好,根据文中的建议,一方面要求审查人要及时进行审查,另一方面又要求提交人进行频繁的原子性提交,这样就会导致审查人的工作会被频繁打断,这样不会影响审查人的工作效率吗?我们团队也是要求开发人员小步快跑,但是这样之后发现审查人的工作又被频繁打断,工作效率又降低了很多

    作者回复: 解决的办法:
    1. 让开发者代码在被审查的时候不被阻塞,还可以做其他的事情。比如我在第26,27篇文章中描述的使用git方式。
    2. 审查者抽出一个时间段集中审查。

    2019-11-18
    1
  • -W.LI-
    老师好!公司的代码规范是用的阿里巴巴开发手册。也和leader沟通过怎么提升代码质量。leader建议多阅读开源项目源码。现状就是忙于业务代码,需求变动,并没太多时间阅读源码,也不知从何入手。以下几个现象比较严重。
    1.为了实现业务老写出一个很长的方法,又找不到合适的角度去拆分这个方法。
    2.无法平衡效率和可读性。
    3.好用的工具库,jdk新特性掌握太少。

    作者回复: 我在对一个比较长的方法进行拆分的时候。通常会先把。这个方法的,所做的操作。按照所做的工作按照步骤进行注释
    ==函数==
    foo() {
      ooo;
      ppp;
      qqq;
      rrr;
    }

    ==1. 把程序分成极大部分,添加注释==
    foo() {
      // Do something A
      ooo;
      ppp;

      // Do something B
      qqq;

      // Do seomthing C
      rrr;
    }

    ==2. 把几个步骤提取出来,从而把foo()缩短==
    DoSomethingA() {
      ooo;
      ppp;
    }

    DoSomethingB() {
      qqq;
    }

    DoSomethingC() {
      rrr;
    }

    foo() {
      DoSomethingA();
      DoSomethingB();
      DoSomethingC();
    }

    这个里面关键在于第一步进行步骤的拆分。仔细对foo的工作思考,一定可以拆小的。

    2019-10-03
    1
  • 不是云不飘
    规范和审查一直由项目赶着上线没有实施,导致现在代码的坏味道越来越多,也没有时间去改,感觉一直恶性循环。

    作者回复: 推荐听一下这篇:
    14 | 质量与速度的均衡:让“唯快不破”快得更持久
    https://time.geekbang.org/column/article/138916

    2019-10-15
  • 二狗
    一个功能怎么拆成多个原子提交,关于原子性提交不是很理解 (日常都是一个功能,一个bug一次提交)

    作者回复: 这是因为通常一个功能可能会很大,如果一整个功能作为一个提交的话,提交可能很大,就像文章中漫画里的巨大星球一样 😀

    做法是把功能差分成几个“子功能”,分别提交。比如说一个功能是提供一个API。如果这个API比较大,我们可以把它拆分成(数据模型+API业务)两个部分。如果这样下来还是很大,还可以继续拆小。比如API业务可以分成(refactor+添加新业务)两个部分。

    总之,是把每一个提交都做成能够独立完成一些任务,但是有不太大。

    2019-09-30
  • Geek_1988
    葛老师,如果太追求代码的原子性,产生很多提交,会不会导致git太庞大而影响运行呢?

    作者回复: 很棒的思考!Git仓库对非常大的代码仓的确会有性能问题。不过追求原子性多产生的提交的量级应该不会太大,一般来说不会对Git的性能造成关键影响。而且每个提交变小了,也会抵消一部分多提交导致的性能下降。

    2019-09-27
  • Alick
    葛老师,能否介绍下 Facebook 代码评审的绩效考评方法?

    基于评审意见数,觉得纬度单一;基于问题严重性,有易起纷争的担忧;

    采取何种代码评审绩效评价方式,能够起到正向积极导向效果?

    作者回复: 评审意见数只能是一个简单的参考。

    在Facebook,对代码评审工作的衡量,主要是通过同事间的主观反馈来获得的。比如我在文中举的例子,我的主管给我的两个反馈,一次是审查不积极,一次是审查太注意细节,都是其他同时反馈给他的。

    2019-09-22
收起评论
7
返回
顶部