高效code review指南
大多数程序员都知道并且相信code review(代码审查)的重要性,但并一定都能很好的执行这一过程,做好code review也需要遵循一定的原则、流程和规范。
我们团队的code review实践也并不是一帆风顺,两年前刚开始的时候,形式很粗糙,就是一堆人对着代码品头论足。导致的结果要么是陷入争论,reviewer说这里写得不好,author(本文中用author这个单词来指代被评审者)辩论说其实没问题;要么只关注一些无伤大雅的细节,发现不了更为严重的问题(比如设计的问题)。试了几次,逐渐感觉流于形式,后来也就不了了之了。
如果发现一个广为推荐的工具不太好用,那么除了怀疑这个工具适不适合之外,更应该想想使用姿势是否正确。于是花了些实践来学习code review的知识,并与其他团队交流,在实践中逐渐形成了一套行之有效的方法。本文记录对code review的一些认识与思考
本文地址:https://www.cnblogs.com/xybaby/p/12601471.html
code review的出发点
我们从一个需求开发的完整生命周期来看,大约会包含以下过程:
- 需求分析,考虑人员情况、功能预期上线时间、技术难度等诸多因素,与PM讨论合理调整需求,分配资源;
- 整体设计,对设计进行review;
- 代码开发;
- 开发自我review,观察、思考与整体设计的出入,保证代码遵循团队规范(至少得通过静态代码检查);
- 添加相应的单元测试,并保证已有的单元测试不受影响;
- code review,请相关同事对代码进行review,修复review中发现的问题;
- 提交代码给QA测试,QA会进行功能测试、集成测试、性能测试、压力测试等;
- 修复测试发现的bug后功能上限。
从上属流程可以看出,代码写完了会有专业的测试同事来进行全方位的测试,那么为什么还要code review呢?其次,合格的程序员理论上都会review自己的代码,还有没有必要请同事来review呢?
一个bug,可能在代码review的时候被发现;也可能在测试的时候被发现;最坏的情况下,被用户发现,当然,此时很可能给用户、产品带来损失。越早发现问题,受影响的人员越少,修复成本就越小。
开发人员有时也有一个误区,觉得自己完成“代码开发”这一步就万事大吉了,测试的事情就应交给QA去执行。但很多时候,QA更多从功能角度去验证代码,有时候黑箱测试也很难覆盖到全部情况,比如异常、安全性问题、版本依赖。况且现在很多公司都逐渐去掉专门的Test,开发得自己测试,但思维定势导致很难发现自己的问题,对自己代码的review也是如此。另外,知道自己的代码也被人“拿着放大镜仔细观察”,自然写代码的时候也认真一些。
另外,从上述流程可以看出:
- 其实应该有两次定位不同的review:对整体设计的review,主要目的是从大方向上保证设计确实能满足需求;其次是code review,保证代码实现符合设计约束,且编码没有明显的缺陷。
- 用来code review的代码,应该既满足团队代码规范,又基本保证功能的正确。
在我们的实践中,对于复杂的系统,会要求现先设计review。而对于简单的、或者开发比较有把握的功能,则是将设计review与代码review合并。本文讨论的code review其实就是后者:既关注设计,又关注核心代码。
code review的目标和原则
code review的首要目标是:找出代码中的缺陷,保证代码质量。其次,通过review也能相互学习,提高团队整体水平,而且特别有利于新人快速融入团队,保持与团队风格一致。最后,保证每个核心功能有多个同事了解,降低风险。
从其核心目标我们就可以看出code review的第一原则:对事不对人。这一点需要reviewer、author达成共识。code review不是批斗大会,reviewer、author并没有高低之分。
对于reviewer而言,参与的首要目的在于协助发现问题,因此
- 尽量质疑自己而不是对方
我没有看懂这段代码的逻辑
而不是
你这段代码有问题吧
- 指出代码有问题而不是指责人
这段代码是不是可能出问题
而不是
你又写出bug来了
对于author,应当把review当作一次学习成长的机会 -- 毕竟平时又有谁来给你免费建议和指导呢?因此,不要一开始就是防御的姿态,即使reviewer有所误解也不用脸红脖子粗的去争论。
要真正让author放松,达到和谐review的效果,个人觉得还要注意以下几点:
- review不应该与任何KPI挂钩,review发现的缺陷不应纳入绩效考核。
- 团队Leader应该少发言(否则就会变成Leader说啥就是啥),甚至要少参加无关的review,毕竟任何人都不希望给Leader留下自己很菜的印象。
- 得需要有人充当仲裁者的角色,化解reviewer与author的冲突。而且,必要的时候维护author。
code review步骤以及注意事项
code review 并不简单是一堆人一起看代码,要让code review的效果最大化,整个流程是需要认真组织的:
review前
- author得保证代码质量:代码满足团队规范且基本测试通过
- author至少提前一天通知参与review会议的同事,提供必要的需求、设计文档
- reviewer简单了解需求、设计、代码实现
这里需要注意的是,与会人员越少越好,无关的同事最好不要参加review。如果与会者对相关的功能不感兴趣,那么就存粹是在浪费时间,这也是很多人不喜欢code review的原因。
review中
review的过程大约是:
- author大致讲解需求和整体设计,然后是核心代码
- reviewer提出问题,author确认是否是问题
- 对发现的问题进行记录,分类处理
review中需要注意:
- 控制review的时间,codereview本身就是一个高强度的活动,时间过长大家都很疲惫,效率也会下降,经验值一个小时左右比较合适。
- 控制review的代码量,需要大家仔细阅读的代码最好也控制在200 - 400逻辑行(这个数值也是the art of unix programming中对模块代码量的建议值)
- 需要有支主持人控场,把控时间和进度。和任何高效会议一样,应该避免发散,尽量只发现问题,并不深入讨论如何解决问题。
- 记录发现的问题,以及相应的解决方案:
- 已有明确修复方案只待执行?
- 还是需要修复但解决方法尚需要进一步讨论?
- 还是在下一次迭代时再修复?
reviewer内容依次是:
- 是否满足功能需求,有没有多做,有没有少做,有没有潜在的bug,
- 是否满足非功能需求。性能(高频调用的函数、核心算法)?可用性(异常处理是否完善)?可读性?
- 代码质量、规范
上面也提到,code review本身是个高强度的活动,因此容易漏掉一些关键点点,因此不妨做一个review list,对照这个list去考察代码。list保证了code review的质量下限,且不影响与会者发挥主观能动性,发现其他问题。
此外,也需要避免在没有明确规范的问题下过多争执。达到同样的效果,A方法可以,B方法也可以,如果团队没有约束用哪种方法,那么就不要在code review的时候讨论。
review后
review会议结束并不意味这个review这个活动结束,因为还有待解决的问题,因此应该借助工具跟踪review发现的问题,指明问题的修复者、问题的验收人、问题的验收时间。当一次review所关联的所有问题都得到修复之后,review活动才算结束。
总结
如何才能code review有效且高效,总结以下几点:
- 会前充分准备,与会人员最少化
- 参考review list,发现问题但不发散去讨论解决问题
- 会后跟进问题修复
最重要的事,是通过几次组织良好的实践让大家看到code review确实是有价值的,有所收获才愿意持续付出。
高效code review指南的更多相关文章
- 从code review到Git commit log
最近在读一本技术类的书:朱赟——<跃迁:从技术到管理的硅谷路径>,其中聊了很多很有趣的观点,比如:技术管理.技术实践.硅谷文化.个人成长等. 读到关于硅谷人如何做code review这一 ...
- Go Code Review Comments 译文(截止2018年7月27日)
持续更新中- 原文最新链接 https://github.com/golang/go/wiki/CodeReviewComments/5a40ba36d388ff1b8b2dd4c1c3fe820b8 ...
- 我们是怎么做Code Review的
前几天看了<Code Review 程序员的寄望与哀伤>,想到我们团队开展Code Review也有2年了,结果还算比较满意,有些经验应该可以和大家一起分享.探讨.我们为什么要推行Code ...
- [充电]Code Review
参考:http://blog.jobbole.com/83595/ http://www.kuqin.com/shuoit/20150319/345323.html 让 Code Review成为一种 ...
- 17款code review工具
本文是码农网原创翻译,转载请看清文末的转载要求,谢谢合作! 好的代码审查器可以大大地帮助程序员提高代码质量,减少错误几率. 虽然现在市场上有许多可用的代码审查工具,但如何挑选也是一个艰巨的任务.在咨询 ...
- 代码审查 Code Review
为什么要做代码审查 代码审查最主要目的是保证软件质量,找出及修正在软件开发过程中的错误.同时,通过不同能力评审者对代码的分析和建议,可以很快提升编码能力和编码修养. 1. 保证软件质量 通常软件开发完 ...
- [行业关键词] review code review
意思是 代码评审 或是 代码回顾 代码评审是指在软件开发过程中,通过对源代码进行系统性检查的过程.通常的目的是查找系统缺陷,保证软件总体质量和提高开发者自身水平. Code Review是轻量级 ...
- Code Review Checklist
左按:当年需要一份详细的代码评审清单作参考,翻译了此文. 版权声明:本文为博主原创文章,未经博主允许不得转载. 目录(?)[-] General Code Smoke Test 通用测试 Comm ...
- Code review应该怎么做
代码评审有两种不同的方法,一种是代码走查,一种是代码审查,我们这里讨论的仅指代码走查.通常自己写的代码都难以发现问题,需要以第二双眼睛再次检查代码,帮助我们及时地发现潜在的问题. 做代码审查之前,团队 ...
随机推荐
- 听起来很美,用起来很累!停车类APP软肋在哪
据数据显示,全国现有汽车已达1亿7千万辆,停车位缺于6800万个.而在北京,汽车保有量和车位的配比大约是1:0.5,而国际上一般是1:1.2,结构严重失衡.正所谓哪里有需求,哪里就有市场.停车位的走俏 ...
- Errors running builder JavaScript Validator
问题: 解决方法: 方法一. 选择对应项目—-右键Properties—-Builders—-取消“JavaScript Validator”的勾就OK了 方法二. 找到“.project”文件,找到 ...
- 微软亚洲研究院开源图数据查询语言LIKQ
近日,微软亚洲研究院通过GitHub 平台开源图数据查询语言LIKQ (Language-Integrated Knowledge Query).LIKQ是基于分布式大规模图数据处理引擎Graph ...
- Python——11面向对象编程基础
*/ * Copyright (c) 2016,烟台大学计算机与控制工程学院 * All rights reserved. * 文件名:text.cpp * 作者:常轩 * 微信公众号:Worldhe ...
- Ueditor富文本编辑器--上传图片自定义上传操作
最近负责将公司官网从静态网站改版成动态网站,方便公司推广营销人员修改增加文案,避免官网文案维护过于依赖技术人员.在做后台管理系统时用到了富文本编辑器Ueditor,因为公司有一个阿里云文件资源服务器, ...
- SpringBoot 全局异常处理 @RestControllerAdvice +@ExceptionHandler 请求参数校验
ControllerAdvice 指示带注释的类辅助“控制器”. 作为的特殊化@Component,允许通过类路径扫描自动检测实现类. 通常用于定义@ExceptionHandler, @InitBi ...
- jspdf + html2canvas 实现html转pdf (提高分辨率版本)
刚解决了html中某div块生成pdf的问题,热乎乎的,赶紧记录下 引入的js传送门: https://cdnjs.cloudflare.com/ajax/libs/jspdf/1.0.272/jsp ...
- vue 不用npm下载安装包 该如何引用js
公司电脑不让用npm ,vue的项目要使用moment.js, 用了各种script 引用,总是报错 正确的方式应该为: import {moment} from ‘moment.js ’ 不可以全 ...
- 自定义添加$_SERVER中的变量
如何根据自己项目中的需求自定义$_SERVER中的变量呢?比如$_SERVER['XU_TEXT_PARAM'],这个超全局变量输出肯定是会报错的.那如何自定义它,让它输出我们想要输出的值呢? 1.在 ...
- Chrome开发者工具之测试应用
一.Chrome开发者工具简介 浏览器的开发者工具(DevTools)可以帮助开发人员对网页进行布局,比如HTML+CSS,帮助前端工程师更好的调试脚本(JavaScript.jQuery)之类的,还 ...