如何防止 A 用户导入数据时 用了user表空间
2007-08-31 12:30
239 查看
一、概述
代码审查(Code Review)是消灭Bug最重要的方法之一,这些审查在大多数时候都特别奏效。由于代码审查本身所针对的对象,就是俯瞰整个代码在测试过程中的问题和Bug。并且,代码审查对消除一些特别细节的错误大有裨益,尤其是那些能够容易在阅读代码的时候发现的错误,这些错误往往不容易通过机器上的测试识别出来。1.1主要工作
1、发现代码中的bug;2、从代码的易维护性、可扩展性角度考察代码的质量,提出修改建议。
3、是否符合java开发规范和代码审核检查表
1.2 基本流程
1、代码编写者和代码审核者坐在一起,由代码编写者按照UC(Use Case)依次讲解自己负责的代码和相关逻辑,从表现层->持久层;2、代码审核者在此过程中可以随时提出自己的疑问,同时积极发现隐藏的bug;对这些bug记录在案。
3、代码讲解完毕后,代码审核者给自己安排几个小时再对代码审核一遍。 代码需要一行一行静下心看。同时代码又要全面的看,以确保代码整体上设计优良。
4、代码审核者根据审核的结果编写“代码审核报告”,“审核报告”中记录发现的问题及修改建议,然后把“审核报告”发送给相关人员。
5、代码编写者根据“代码审核报告”给出的修改意见,修改好代码,有不清楚的地方可积极向代码审核者提出。
6、代码编写者 bug fix完毕之后给出反馈。
7、代码审核者把Code Review中发现的有价值的问题更新到"代码审核检查表"的文档中,对于特别值得提醒的问题可群发email给所开发人员。
1.3 责任
代码编写者,代码审核者共同对代码的质量承担责任。这样才能保证Code Review不是走过场,其中代码编写者承担主要责任,代码审核者承担次要责任。二、java代码审查检查表
重要性 | 激活 | 级别 | 检查项 |
总计 | | | |
命名 | | | |
重要 | | 20 | 命名规则是否与所采用的规范保持一致? |
| | 20 | 是否遵循了最小长度最多信息原则? |
重要 | | 50 | has/can/is前缀的函数是否返回布尔型? |
注释 | | | |
重要 | | 10 | 注释是否较清晰且必要? |
重要 | Y | 10 | 复杂的分支流程是否已经被注释? |
| | 10 | 距离较远的}是否已经被注释? |
| | 10 | 非通用变量是否全部被注释? |
重要 | Y | 50 | 函数是否已经有文档注释?(功能、输入、返回及其他可选) |
| | 10 | 特殊用法是否被注释? |
声明、空白、缩进 | | | |
| | 20 | 每行是否只声明了一个变量?(特别是那些可能出错的类型) |
重要 | | 40 | 变量是否已经在定义的同时初始化? |
重要 | | 40 | 类属性是否都执行了初始化? |
| | 20 | 代码段落是否被合适地以空行分隔? |
| Y | 20 | 是否合理地使用了空格使程序更清晰? |
| | 20 | 代码行长度是否在要求之内? |
| | 20 | 折行是否恰当? |
语句/功能分布/规模 | | | |
| | 20 | 包含复合语句的{}是否成对出现并符合规范? |
| | 20 | 是否给单个的循环、条件语句也加了{}? |
| | 20 | if/if-else/if-else if-else/do-while/switch-case语句的格式是否符合规范? |
| | 40 | 单个变量是否只做单个用途? |
重要 | | 20 | 单行是否只有单个功能?(不要使用;进行多行合并) |
重要 | | 40 | 单个函数是否执行了单个功能并与其命名相符? |
| Y | 20 | 操作符++和— —操作符的应用是否复合规范? |
规模 | | | font-size:
相关文章推荐
|