标签:
对于很多公司来说,代码审查是开发人员日常工作中的重要环节。通过代码审查,可以及早发现项目中存在的问题、促进同事之间的沟通与交流,并且可以在讨论中迸发出智慧的火花。但要想成功实施代码审查却并不是一件轻松的事情,为什么要进行代码审查、何时做、如何做,这是摆在我们面前的3个重要问题。针对于这3个问题,开发者Lisa Tjapkes撰文谈到了自己的经验与教训。
在我最近的项目经历中,我们进行了广泛且正式的代码审查。这个过程极大地改进了项目的代码质量,降低了项目中新特性开发的等待时间,同时还促进了知识在整个团队间的传播与共享。我还发现代码审查并不会延误项目开发的时间,反而会提升开发人员的生产力。
代码审查的好处
我们发现代码审查对于项目的各个阶段都会带来很多好处:
高效代码审查的技巧
代码审查的方式如果处理不当可能会导致项目延期。使用正确的工具与技术可以防止在审查上浪费大量的时间,提升代码的品质。
使用特性分支
这个实践的好处就不用多说了,不过它对代码审查提供了更加具体的好处。特性分支意味着你可以将需要审查的代码隔离到只与某个具体的特性相关。在代码已经准备好了审查时,特性分支还考虑到了快速的上下文切换。在当前的代码进行审查时,你可以切换到新的特性上来,如果需要对审查特性的反馈进行讨论时还可以快速切换回来。
将审查隔离为小的修改
相对于大的修改来说,小修改的审查时间会更少。在审查大的修改时,你不仅要看很多行代码,还要查看大量的依赖代码才能真正理解,结果就是花在审查代码上的时间与修改的代码量之间并不是呈线性关系。将待审查的代码隔离为小的修改可以降低审查者的精神负担并让审查过程更加顺畅。
使用专门为代码审查而设计的工具
这看起来似乎很简单,但却非常重要。一些重要的特性需要包含差异比较、能够逐行注释修改,并且在审查的代码发生改变时通知大家。我所在的团队使用GitHub来管理项目代码,并且使用GitHub的pull request特性来管理代码审查。
检查清单
可能没必要使用非常复杂或是过于结构化的东西,如果突然出现了某些问题,使用检查清单或许是个不错的主意。
有建设性的输入
类似于“多加点注释”这样的话显得太没意义了,帮助也不大。假如某个接口没有注释,但也许有专门的文档用来说明呢。如果发现了某些不合理的地方,那就要明确指出来,判断设计上是否能改进或是逻辑上是否存在着错误。
要把精力放在真正理解代码的行为上,确保当其他人需要维护它时也能够快速理解代码。
人人参与
即便是最有经验的架构师或是明星开发者也会犯错。因此,最好每个人都能参与到代码审查的过程中来。特别地,对于很多初级开发者或是新加入项目的开发者来说,这也是个很不错的学习机会。
要有审查流程
一开始,我们的项目并没有正规的审查流程。我们只是开启一个pull request,等待有人来审查,最后会有人合并修改。这种工作方式效率非常差,有时好几天都没人审查一个pull request,有时一个人给出反馈前其他人却合并了请求。此外,有些开发者审查的代码量要比其他人多不少。总而言之,没有流程导致我们的效率极低。
最后我们认识到了这一点,创建了一个正式的结构来指导该如何进行代码审查,这加速了审查的效率。一个审查过程至少应该涵盖如下几点:
我在项目中是否应该进行代码审查?
我认为代码审查对于很多项目来说都是一件好事,不过它也并非通用的解决方案。代码审查适合于如下这些项目:
相反,代码审查在如下的情形中并不会为项目带来更多的附加值:
http://kb.cnblogs.com/page/192748/
标签:
原文地址:http://www.cnblogs.com/softidea/p/4896019.html