代码评审工具Jupiter使用流程Word格式.docx
《代码评审工具Jupiter使用流程Word格式.docx》由会员分享，可在线阅读，更多相关《代码评审工具Jupiter使用流程Word格式.docx（13页珍藏版）》请在冰豆网上搜索。
2012-03-29
1.1
根据最新的插件界面更新文档，完善了使用流程和记录导出功能
2012-04-16
目录
1概述4
2目的4
3适用范围4
4基本原则4
5角色职责5
6评审内容5
7安装Jupiter7
8使用Jupiter进行代码评审7
8.1准备代码7
8.2代码评审12
8.3会议讨论13
8.4修改代码13
8.5记录结果14
1概述
什么是代码评审（CodeReview）?
代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。
Jupiter提供了代码行级别的评审批注功能，方便评审参与人了解具体是哪些行代码存在问题。
同时，它也比较符合常规的评审流程，被评审人提供待审代码->
评审人线下提出个人意见->
组织讨论会讨论每个人提出的意见并确定问题及解决方案->
被评审人修改代码->
评审人查看修改情况。
Jupiter支持在一个项目中的多次评审，多人协同参与评审，支持多种配置库如SVN、CVS等，支持简单的评审流程，支持问题跟踪。
2目的
定期进行CodeReview可以有效的降低开发风险，除此之外，代码评审还有以下好处：
◆提高代码质量
◆在项目的早期发现缺陷，将损失降至最低
◆评审的过程也是重新梳理思路的过程，双方都加深了对系统的理解
◆促进团队沟通、促进知识共享、共同提高
3适用范围
所有研发部门
4基本原则
没有人否认CodeReview对提高代码质量的作用，但是如何进行CodeReview?
这里确实存在一些方法和技巧。
方法不当，会浪费大量时间、造成低效率；
流程过紧，会大大降低生产力，流程过松，很难知道CodeReview的效果，甚至有没有进行CodeReview，都很难判断，这里有10条代码评审的最佳原则：
◆一次检查少于200～400行代码
◆努力达到一个合适的检查速度：
每小时少于300～500行代码
◆有足够的时间、以适当的速度、仔细地检查，但不宜超过60～90分钟
◆在复审前，代码作者应该对代码进行注释
◆建立量化的目标并获得相关的指标数据，从而不断改进流程
◆使用检查表（checklist）肯定能改进双方（被评审人和评审人）的结果
◆验证缺陷是否真正被修复
◆管理人员要营造良好的氛围（文化），使大家可以积极地对待缺陷的发现，发现足够多的缺陷，只关心问题是什么、怎样引起的，而不关心是谁写的代码
◆自我约束：
即使没有时间完成所有代码的检查，也应该尽可能去做，哪怕是一部分
◆轻量级的codereview是高效率的、可行的，并能有效地发现缺陷
5角色职责
◆评审组织者：
负责制定CodeReview计划，安排CodeReview活动职责分工，组织进行CodeReview，确保按CodeReview过程和规范执行。
◆评审人和被评审人：
依据CodeReview计划和CodeReview过程和规范执行CodeReview活动。
6评审内容
◆工具检查
□Eclipse警告
□FindBug
□CheckStyle
□Jupiter
□Subclipse或者Subversive
◆代码注释内容（详细参考《代码注释规范》）
□类注释内容
□接口注释内容
□方法注释内容
□方法内部注释内容
◆业务逻辑
□业务逻辑实现的正确性
□业务逻辑实现的完整性
◆代码细节
◆异常处理
□接口方法声明需要抛出BusinessException
□接口实现类最外层需要强制try….catch,对Exception进行marshBusinessException包装
□禁止出现try….catch后，没有对异常做任何处理的情况
□在EJB边界对所有的异常进行marshBusinessException包装
□后台所有方法不再显示的进行异常的抛出声明，如有异常用wrappBusinessException包装成运行时异常直接抛出
□前台代码直接抛出后台传递过来的异常
□前台代码主动抛异常时，需要使用ExceptionUtils.wrappBusinessException;
□前后台异常处理类统一使用nc.vo.pubapp.pattern.exception.ExceptionUtils
□未用异常作为业务流程转换的判断
◆效率
□接口的定义使用参数数组来进行批量调用，而不是循环调用非批量接口
□方法内部禁止出现循环执行相似重复的SQL语句
□尽量使用绑定变量的sql
□sql关联的表不超过3个
□sql不采用外连接
◆内存
□UFDobule常量必须使用UFDouble.ZERO,UFDouble.ONE
□UFBoolean常量必须用UFBoolean.TRUE,UFBoolean.FALSE
□UFBoolean的值必须采用UFBoolean.valueof（true|false|y|n|Y|N），的形式进行构造
◆其他
□临时表命名方式为:
TEMP_（模块名称）_（具体作用）例如：
temp_gl_assidtemp_fa_depdata
□常量要使用NC枚举类
□加锁应用统一的工具类，一定先加锁再查询
□代码中访问数据库都用相应的VO类，禁止直接使用JDBC
□面向接口编程
□方法入口处不能对传入参数进行容错处理
□VO的get/set方法中不能包含业务逻辑
□VO中不能有业务方法，也不能有数据校验方法
□避免全局变量
注：
代码评审不负责检查功能、逻辑是否正确，这些要靠单元测试和QA工作来解决
7使用工具审查
安装Jupiter
Jupiter作为Eclipse的插件，安装起来非常方便，只需拷贝edu.hawaii.ics.csdl.jupiter_3.6.jar至$ECLIPSE_HOME/plugins目录下，重启Eclipse即可，如果看到Eclipse的工具栏上出现了Jupiter的图标
，则表示安装成功
8使用Jupiter进行代码评审
代码评审分为两种方式，一种是交叉评审，另一种是代码会审。
交叉评审又称为代码走查，即团队成员互相检查代码，参与者可以是任意两个组员，或开发组长分别与每个组员结对进行，时机可以选择在下班前半小时，对当天改动的模块进行评审，代码作者讲解如何以及为何这样实现、评审者提出问题和建议，每次解决的问题要记录到SVN或CVS服务器，每次评审代码不宜太多，否则会事倍功半。
代码会审主要用于开发阶段的重点模块集中Review，它采用的是正式的会议Review，参与者包括项目组全体成员，其它组的开发组长也应尽量参加，时机选择，一般是开发进行到某一阶段时，对共性问题进行总结，对好的做法进行提炼和推广。
二者的评审流程基本一致，区别在于代码会审要开会讨论审查结果，下面就以会议评审为例详细讲解如何使用Jupiter进行代码评审
代码评审分为5个阶段，分别是准备代码、代码评审、会议讨论、修改代码、记录结果
8.1准备代码
●在Eclipse中打开要评审的项目的属性选项卡，选中Review标签
●点击“新增”按钮，新建一个评审计划，输入评审编号和描述；
评审编号规则：
姓名_创建日期，示例如下图所示：
●添加要评审的java文件
●添加此次评审的评审参与人员，人员使用真实的姓名
●指定被评审人
●选项设置，使用默认设置即可
●默认选项设置，使用默认设置即可
●存储路径设置，路径设置规则：
review\\创建日期\\被评审人，示例如下图：
●过滤器设置，使用默认设置即可
●点击Finish按钮，评审组织者提供待审代码的工作就完成了，Jupiter将在项目根目录下生成“.jupiter”文件，评审组织者需要将此文件提交至SVN服务器，然后邮件通知其它评审人员进行代码评审了
8.2代码评审
●在工具栏上选择Review按钮下的“1个人评审”
●在代码评审过程中，发现有问题的代码，即可先选中有问题的代码，然后点击右键，点击AddReviewIssue...或者点击ReviewTable上的“+”，把问题添加到Jupiter中，在ReviewEditor指定问题类型、严重性和描述信息，问题类型和严重性必须选择
●完成个人的代码审查后，把Jupiter评审数据目录下的文件提交至SVN，然后通过邮件通知评审参与人员准备小组讨论。
8.3会议讨论
●从SVN上取出最新的.jupiter文件，在工具栏上选择Review按钮下的“2小组讨论”
●个人审查里检查出的所有的问题都会显示在ReviewTable里，双击就能链接到问题所在代码，然后大家讨论这段代码是否有问题，如何解决等等，把结果写到ReviewEditor里，保存；
注意修改人和决议必须设置
●所有的问题讨论处理完后，把Jupiter评审数据文件上传至SVN，然后通过邮件通知被评审人修改代码。
8.4修改代码
●在工具栏上选择Review按钮下的“3修改阶段”
●修改自己的代码，并更改状态，而且状态必须设置
●全部问题都修改完成后，把Jupiter数据上传至SVN服务器
8.5记录结果
●待所有问题都解决后，要将CodeReview的结果导出进行存档；
可以通过下图的两种方法导出结果：
●导出的代码审查记录单存放在review文件夹下，位置和格式如下图所示：
9后续扩充
升级会员 