码迷,mamicode.com
首页 > 其他好文 > 详细

谈如何做好代码审查?

时间:2018-07-02 14:52:08      阅读:188      评论:0      收藏:0      [点我收藏+]

标签:思路   批注   不容易   轻松   会议   成长   重构   开发   那是   

1.什么是代码审查?

    代码审查英文为Code Review,是提高开发团队技能以及保持团队迭代更新最佳的实践方法,也是代码质量管理中一个非常有效的方法。

Code Review中文译作“代码审查”或是“代码评审”,这是一个流程,当开发人员写好代码后,需要让别人来review一下他的代码,我们可以审查代码的风格、逻辑、思路……,找出问题,以及改进代码。因为这是代码刚刚出炉的时候,所以,这也是代码重构,代码调整,代码修改的最佳时候。所以,Code Review是编码实现中最最重要的一个环节。

 

Code Review原本是整个流程中不可或缺,且较为耗时的一个质量保证环节,虽省略之后给业务方造成单位时间生产效率更高的假象,但低质量的代码,会把团队带入漩涡,滚雪球一样的技术债,会让团队付出巨额利息。

1、保证项目质量、提高代码可读性
  • code review可以通过reviewers的建议增进代码的质量,也能提高owner的编程态度
  • code review有利项目流转,可以让其它并不熟悉代码的人知道作者的意图和想法,从而在以后轻松维护代码
  • code review鼓励程序员们相互学习对方的长处和优点,同时可以达到知识传播
  • code review可以用来确认自己的设计和实现是清楚和合理的
  • code review帮助找到程序的bug和保证代码风格和编码标准
2、加速个人成长、突出团队价值

个人的技能成长不再只依靠自己或技术主管的建议,整个团队对单人的成长都能起到帮助,成员可以获得别处无法达成的发展 
从而进一步促进整个团队生产力的提升,最终项目进度和品质都能得到很好的保障

 

那为什么有些人偏偏不愿意进行CodeReview呢?

  1. 时间不够问题:业务倒逼工期,时间太紧,连coding都勉强,以上线为目的。解决方法:其实这不是CodeReview的问题,这是需求管理与项目管理的问题
  2. 需求变化问题:需求变得快,代码的生命周期太短,所以都写一次性烂代码。解决方法:临时代码不是单独存在的,会影响长期在用的代码,会影响长期稳定的技术团队。
  3. 人员态度问题:不想精益求精,干活交差为主。解决方法:那么更需要Review来保障质量和促进上进了。

 

好吧,既然这么好,那是不是任何团队都合适实施呢?

当然不是,你团队中的项目得满足以下前提条件:

  1. 统一的标准:没有评审标准的评审是混乱的
  2. 只实施于高价值模块:关注在核心系统代码、重用的组件等对质量有高要求的模块,而快速抢占市场的迭代型项目可在交付后再补Review
  3. Reviewer奖励机制:reviewer的评审会占用工作量,是项目质量的保证者,贡献者,应建立适当鼓励机制与每月绩效关联
  4. 代码充分注释:要求核心代码,加上充分的业务注释、逻辑注释,以便reviewer更易理解代码思路
  5. 先跑CodeStyle检查工具:不应该把人工CodeReview的精力放在指出代码样式和规范上,所以代码请先用插件跑一遍CodeStyle自行检查与修改

 

好了,我一切准备就绪了,具体怎么实施呢?

我建议有2种做法:

  • 方法一:代码评审会议,我称之为Code Review Meeting,就是将团队成员都组织起来开会,让代码Owner上去讲自己代码的实现和思路,其它人发表意见和进行讨论。
  • 方法二:一对一评审,我称之为Single Review,就是项目owner提交代码之后,让reviewer在空闲的时候帮忙评审代码,并且写出批注,owner收到批注后,进行修改或者回复。但注意这里的reviewer并不是只有技术主管或架构师之类的才能做,代码质量监管仅仅靠架构师是不够的,需要所有经验丰富或有专长的同学参与其中。

 

那Single Review与Review Meeting根本上哪些不同呢?

一、Review Meeting

  • 优点: 
    • 团队内新技术/新观点的交流Meeting、项目开发思路、解决方案讨论,偏头脑风暴式;
    • 各类项目都适合进行;
  • 缺点: 
    • 依赖于主持者(项目Owner)的素质、时间成本高(为会议上所有人时间的总和);
    • 集体评审的代码行数有限;

二、Single Review

  • 优点: 
    • 更偏重与具体的代码评审,人员分散参与,评审代码行数有保证;
    • 时间自由,Reviewer什么时候进行评审时间可自控;
  • 缺点: 
    • 流程稍复杂,只适用于重要项目或核心模块;


以前我们团队每周只进行 Review Meeting,从会议产出和面谈反馈来看,确实有一些的作用。但也不可否认的是,其中是有些弊端的,例如Meeting时评审的代码量很有限,且一些细节问题不容易暴露等等,但这却又是项目质量管理的重点。

那怎么办呢,后来也引入了Single Review,采用Review Meeting与Single Review相结合的模式。 
即每次代码提交后,针对代码的变更进行Single Review,然后每周进行一次Review Meeting。

谈如何做好代码审查?

标签:思路   批注   不容易   轻松   会议   成长   重构   开发   那是   

原文地址:https://www.cnblogs.com/ZJOE80/p/9253605.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!