如何作好Code Review

Code Review(代码审查)不少团队都会作,效果如何很差说。若是你能轻易地从一堆出自正经团队之手的代码里找出几个低级错误,每每意味着团队管理者长期忽视了Code Review的重要性。程序员

根据经验,匆匆应付功能实现和漏洞修复而将Code Review流于形式的团队不在少数。固然,每一个人都能列举一大堆“客观缘由”,并且每一条理由听起来都是那么的有说服力。然而,没作好就是没作好,狡辩只会让场面变得更加恶心。编程

What(什么是Code Review)

A code review is the process of examining written code with the purpose of highlighting mistakes in order to learn from them.编程语言

-- Techopedia学习

这是目前我见过对Code Review最言简意赅的定义。其实怎么描述并不重要,重要的是咱们要达到什么样的目的。优化

Why(为何要作Code Review)

提升代码质量是程序员端稳饭碗、少挨点儿骂的最有效途径。其实Code Review就是很好的相互切磋、共同进步的机会,效果要比独自埋头干啃《21天精通×××》之类的“宝典”好得多。固然,前提是目的明确、态度端正。编码

Code Review主要目的就两个:code

查错

Code Review不是用来查找低级错误的,而是参与者以提交者之外的视角阅读和审视代码,尽量地找到逻辑上的问题。对象

学习

与其说Code Review重在找到问题,不如说其核心目的在于营造团队学习氛围、提高成员对软件品质的追求。我经历过很多团队,为了营造学习氛围,生拉硬拽地要求成员按期举行技术分享会,结果每每敷衍了事、不了了之。资源

How(怎样作Code Review)

下面根据Code Review中涉及的主要人物角色来说讲我推荐的方式。注意,这不是标准答案。开发

具体划分角色责任以前,我建议每一个技术团队都要找到并严格执行适合本团队技术栈的编码规范,甚至包括IDE配置和开发环境参数设定等,以确保每位成员都“说着一样的语言”,并减小在命名规则、排版样式等方面的争论,将时间和精力聚焦到对功能实现和业务优化这些实质性的问题上来。

开发小组技术负责人

每一位开发小组技术负责人都应该积极实施并维护Code Review机制,要求每位成员在提交代码的时候,都必须通过交叉Review,也就是每一次代码提交到主干时,都必须通过另外一位相同技术领域同事的Review,不然将被视为提交了与存在编译时错误的代码同等的严重过失。

每次代码提交的交叉Review,开发小组技术负责人应当随机抽取包括本身在内的任何一位技术人员进行,不要让提交者可以很轻易地预知将会是谁来作本身这一次的Reviewer,不然很容易变成形式主义。

而且,对于Feature实现的Code Review,开发小组技术负责人应该较为频繁但不按期地进行公开Review。组织一场会议,召集整个开发小组的成员一块儿对这次提交的代码进行审查。

提交者

不论Code Review是私下的仍是公开的,提交者都不能提交任何存在编译时错误的代码,这是很是低级的错误。首先在提交代码以前再次进行编译,是确保即将提交的代码不存在编译时错误的必要步骤。其次,也是不少人容易疏忽的,确保本次新增的本地资源文件都被加入了源代码管理,不然即便本地能编译经过,别人拿到你的代码也依然存在编译时问题。

提交代码以前,本身先diff一下,首先确保代码不存在前面提到的诸如命名、格式等方面的低级错误;而后肯定本身对每一处代码变更的理解都很是明确,而且本身已经找不出改进方案;最后确保全部Hard Code都已经被移除,这一点能够参考我以前写的《没什么技术含量的Remove Before Flight》

提交者在代码被Review以前,还应该调整好心态,把别人的询问、质疑、建议、批评,统统视做可能的提高机会,而不要主观上认定本身给出的就是最优解,而别人都是“不明真相的围观群众”。也许别人在不了解背景信息或上下文的状况下,给出了错误的建议,提交者也应当将此做为锻炼思惟和口才的友好辩论,而不是玻璃心受到了侵犯似的直接怼回去。

参与者

参与者应该对编码规范了然于心,对于代码中每一处不符合团队现行编码规范的地方都要不厌其烦地标注出来。不少人认为这个无所谓,反正机器最后读的都是0和1——对,机器只认识0和1,因此源代码实际上是写给人看的。无论代码由多少人写就,最终看上去如同出自同一人之手,这种代码的阅读体验和效率绝对要比那种百家争鸣式的好得多。

若是是面向对象的编程语言,参与者应当考察提交者对抽象的理解和实践,是否准确以及是否过浅或过深。抽象过浅,看上去每每是大杂烩;抽象过深,读起来显得吃力。对于这两种状况,参与者均可以提出本身的见解和建议,不要抱着“你这不行,听个人”的态度,不然很容易造成对立的情绪,进而影响团队对Code Review的积极性。

对于代码实现是否存在改进空间这个问题,参与者应该在阅读新代码时,尽量全面地去理解问题域、了解需求的具体细节,而不是想固然地抛出质疑和意见,给人以浮躁的印象。若是参与者肯定本身清楚地理解了需求和问题,依然对当前的代码实现有改进建议,那么就大胆地提出来,这就是Code Review的核心目的!

相关文章
相关标签/搜索