13 | 代码审查：学习Facebook真正发挥代码审查的提效作用
该思维导图由 AI 生成，仅供参考
引入代码审查的步骤和方法
1. 代码审查应该计入工作量
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文总结了代码审查的重要性以及引入、推进和持续做好代码审查的关键步骤和原则。首先，团队需要达成共识，将代码审查纳入工作量和绩效考评，并选择试点团队进行推行。其次，成功推进代码审查的关键操作包括注意提交的原子性和审查中关注提交说明。最后，持续做好代码审查需要结合机器审查和人工审查，并选择适合团队的审查工具和配置流程。文章还强调了代码审查的两个关键原则：互相尊重和提高提交说明的质量。通过遵循这些原则，团队可以更有效地进行代码审查，提高代码质量和团队效率。文章内容丰富，提供了实用的建议和思考题，适合技术团队参考和讨论。
《研发效率破局之道》，新⼈⾸单¥59
全部留言(16)
- 最新
- 精选
john_zhang我们推行过一段时间代码审查，因为三五个人，所以采用的是团体审查，每天半个小时左右，可惜后来开发进度赶，慢慢就没做了，现在开发同事总是以进度赶为由，不太认同代码审查，怎么破？作者回复: 从点赞的数量来看，大家对这个问题是比较感兴趣的。我建议以下几个办法： 1. 团队统一思想，代码审查是有效工作的一部分，应该计算到工作量里面 2. 减少团体审查，选择更多使用工具进行1对1的审查。前者很难做到效率高。应该只是针对一些重点的提交采用这种方式。 3. 培训团队，统一认识，让大家了解到代码审查的长期收益，让大家不能不能只看到当前的开发进度这个短期收益，还要考虑代码可维护性以及后续添加新功能的速度这些长期收益。甚至可以坚持推动代码审查这个操作作为团队的制度。 后面的答疑文章我会作进一步的讨论。
2019-09-20225
-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-033
bidinggong的确如此，必须把代码审查纳入工作量和绩效考核才能真正落实。作者回复: ������������
2020-10-222
紫色天空1.主观问题：基于代码评审意见作为绩效考评，感觉这个不是很好衡量，这部分是不是占的比能太大，如果占比不太大的话，是不是又会导致某些客观条件下大家不太重视去做代码审查了 2.客观问题：是不是刚开始或者对新手，比较容易提出问题，比如设计上，重构的几大方向上，复杂度上，性能上等。等大家经过一段时间互评后，基本很难找到问题了。此时再遇上比如紧急需求，紧急上线等，大家就会可能没时间review了。所以是不是大家多培训讨论，基本拉齐到同一水平，对代码质量也不错，然后就…又不review了作者回复: 1.主观问题：基于代码评审意见作为绩效考评，感觉这个不是很好衡量，这部分是不是占的比能太大，如果占比不太大的话，是不是又会导致某些客观条件下大家不太重视去做代码审查了 这个的确是不太好衡量。我觉得应该是一个团队组逐渐成一个基准线，也就是一个大家觉得都默认合适的重要性。这个占比应该是团队主管逐步摸索确定。 2.客观问题：是不是刚开始或者对新手，比较容易提出问题，比如设计上，重构的几大方向上，复杂度上，性能上等。等大家经过一段时间互评后，基本很难找到问题了。此时再遇上比如紧急需求，紧急上线等，大家就会可能没时间review了。所以是不是大家多培训讨论，基本拉齐到同一水平，对代码质量也不错，然后就…又不review了 这个好像不会。在Facebook几年，做Code Review都一直很认真，所花时间一直也都比较稳定，并没有出现最后不需要Code Review的情况，而且所花时间还不少（我当时团队占比应该在20%左右）。我觉得，当公司、团队成熟之后，时间占比会稳定，但是应该不会降到很低。
2020-06-152
Joe Black非常好的一节课！其实代码审查还有一个重要的作用，就是能提前发现潜在的bug，尤其是在开发人员水平不太一致的时候。高水平程序员通常一眼就能发现潜在的代码问题。作者回复: 是的。审查时找到bug，成就感也不错！
2020-02-152- Donald你好，从目前互联网发展的形势来看，现在越来越的公司的测试人力越来越少，开发测试比越来越高，但是开发对测试的要求却丝毫没有降低，同样要求测试需要对质量保障负责。所以，我想问一下，有什么好的方案解决这个问题吗？
作者回复: 我觉得终极方法就是全栈开发。测试团队提供工具、平台，由开发人员自己做测试。参见第8、17、18篇文章，
2020-02-041 
Just for fun老师您好，根据文中的建议，一方面要求审查人要及时进行审查，另一方面又要求提交人进行频繁的原子性提交，这样就会导致审查人的工作会被频繁打断，这样不会影响审查人的工作效率吗？我们团队也是要求开发人员小步快跑，但是这样之后发现审查人的工作又被频繁打断，工作效率又降低了很多作者回复: 解决的办法: 1. 让开发者代码在被审查的时候不被阻塞，还可以做其他的事情。比如我在第26，27篇文章中描述的使用git方式。 2. 审查者抽出一个时间段集中审查。
2019-11-181
二狗一个功能怎么拆成多个原子提交，关于原子性提交不是很理解 （日常都是一个功能，一个bug一次提交）作者回复: 这是因为通常一个功能可能会很大，如果一整个功能作为一个提交的话，提交可能很大，就像文章中漫画里的巨大星球一样 😀 做法是把功能差分成几个“子功能”，分别提交。比如说一个功能是提供一个API。如果这个API比较大，我们可以把它拆分成（数据模型+API业务）两个部分。如果这样下来还是很大，还可以继续拆小。比如API业务可以分成（refactor+添加新业务）两个部分。 总之，是把每一个提交都做成能够独立完成一些任务，但是有不太大。
2019-09-301
于小咸葛老师，如果太追求代码的原子性，产生很多提交，会不会导致git太庞大而影响运行呢？作者回复: 很棒的思考！Git仓库对非常大的代码仓的确会有性能问题。不过追求原子性多产生的提交的量级应该不会太大，一般来说不会对Git的性能造成关键影响。而且每个提交变小了，也会抵消一部分多提交导致的性能下降。
2019-09-271- bidinggong引入代码审查的三个步骤：一是，就代码审查的工作量达成共识；二是，选择试点团队；三是，确定审查工具和流程。拿走了，谢谢老师
作者回复: 你做了很多笔记啊！赞一个！
2020-10-22
