Code Review小结

本文将对Code Review进行一个小结。



[b]什么是Code Review？ [/b]

Code Review代码评审是指在软件开发过程中，通过对源代码进行系统性检查的过程。通常的目的是查找各种缺陷，包括代码缺陷、功能实现问题、编码合理性、性能优化等；保证软件总体质量和提高开发者自身水平。 Code Review是轻量级代码评审，相对于正式代码评审，轻量级代码评审所需要的各种成本要明显低得多，如果流程正确，它可以起到更加积极的效果。正因如此，轻量级代码评审经常性地被引入到软件开发过程中。



[b]Code Review的目的是什么？ [/b]


我想Code Review的目的是在实现现有需求的基础上，查看一下已有代码是否做到足够的整洁，有无缺陷，在保证质量的同时，去发现代码中存在的不足，防止存在的缺陷延伸到下一个高版本的代码发布。



[b]Code Review如何开展？ [/b]

个人在几个项目中的Code Review大致经历了两个阶段。第一个阶段我暂时称之为“缺少追踪的阶段“。第二个阶段是”拥有追踪功能的阶段“。



首先来看第一个阶段的code review吧。

在这个阶段Code Review可以分为组内和组间的code Review。

组内小组成员如A 和 B，在完成自己功能模块的同时，互相查看对方的代码，看看里面的有哪些地方可以做的更好。

在这个阶段是否有重复代码，命名是否符合规范等都将是查看的对象。

比如字符串相加的时，是否使用了StringBuilder / StringBuffer代码+操作。

项目中对字符串是否为空有自己的判断，比如已经有StringUitls.isEmpty()方法来检查一个字符串是否为空。如果代码中还有 if(stringValue != null)等判断，我们将会提出意见使用StringUitls.isEmpty()方法代替。这样将使得代码符合项目的规范，让代码更加统一，整洁。



组内之间的code review一般以meeting的方式进行，架构师，项目技术经理，各个组的Team Leader一起聚在一个会议室内对某一个组的代码进行审查。



在这个过程中，除了否有重复代码，命名是否符合规范，有些逻辑是否覆盖了所有的场景等都是需要讨论的对象。

这种方式很容易将项目组的人聚在一起，相互沟通交流，随时可以进行，持续的时间不会太长。但是这个中方式有一个弊端，那就是别人提出的意见或建议不能很好地区追踪到，最后，某个组是否按照修改意见来完成修改将无法追踪到，其它组的成员只会给出意见或建议，但是并没有义务去追踪修改的代码。





[color=blue][size=large][b]第二个阶段 – 可追踪的阶段。[/b] [/size][/color]


后来做过一个美国的项目，该客户很重视Code Review这块，老外的项目做起来还是蛮有规范的。



外国的项目较多的是使用JIRA对issue或者新功能进行记录和追踪，项目采用git对代码进行版本控制。使用Jenkins对代码持续集成。相关的代码进行提交后能够在JIRA有个source TAB 上看到所提交的代码。我们可以使用Crucile对代码进行审查，注释，记录结果

Crucible是一个用于开发团队的代码检测工具，有了Crucible团队成员可以检查、注释、编辑代码，并记录结果。当发现一个潜在的代码问题，你可以挑选出这条代码行并做注释。



到这个阶段，所有的代码都可以指定一个或多个reviewer去审查，当他们接收到code review的请求时，他们会找时间去完成代码的审查，并对某段代码给出审查意见。然后，发出code review请求的开发人员可以收到代码审查的邮件，开发人员根据审查意见调整代码并给出回复。直到最后将所有代码的code review完成为止。



在这个阶段中，所有的代码将有代码审查者，所有的代码修改意见等都可以追踪到，个人觉得这个是目前为止经历的最好的code review方法，有人审，有历史追踪，一目了然。

原文出处： [url]http://www.wangmengjun.com/showArticleDetail.do?articleId=49&cid=1[/url]