请教前辈们在工作中代码走查是怎么做的

江潭素月 · 发表于 2010-8-23 13:48:31

公司要求做代码走查，可是大家之前都没弄过，所以只能在网上搜，倒是搜了些资料。还有关于代码走查检查审查的区别，看得有些晕。
请问前辈们，在实际的工作中，代码走查工作是如何做的呢？难道只是检查代码规不规范之类的，找出哪里不规范，然后写个代码走查单？

补充（主要检查如下内容）
代码注释是否写，是否规范
代码逻辑是否正确
是否有重复代码
是否有更好的实现方式等

[ 本帖最后由江潭素月于 2010-8-24 13:47 编辑 ]

楠族开心果 · 发表于 2010-8-23 15:25:58

这个属于白盒测试吧？没有执行过……

楠族开心果 · 发表于 2010-8-23 15:27:00

代码走查(code walkthrough)和代码审查(code inspection)是两种不同的代码评审方法, 　　代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的。　　最近对项目组进行代码评审，发觉需要对代码评审中找到的问题进行一下分类，大概可以分成以下几类问题：　　1. Comment 　　注释没写，或者格式不对，或者毫无意义　　2. Coding Standard 　　没遵守代码规范　　3. Existing Wheel 　　重复现成的代码，或者是开源项目，或者公司已有代码　　4. Better practice 　　Java或者开源项目，有更好的写法　　5. Performance bottle and Improvement 　　性能瓶颈和提高　　6. Code Logic Error 　　代码逻辑错误　　7. Business Logic Error 　　业务逻辑错误　　代码审查列出问题的类型，并有解决情况报告

楠族开心果 · 发表于 2010-8-23 15:27:16

网上找的，仅供参考

江潭素月 · 发表于 2010-8-23 16:33:01

呵呵，这是“代码走查”百度百科上的吧，我都查了，但是领导让我写出个规范来，有点丈二的和尚摸不着头脑

愚人 · 发表于 2010-8-23 16:58:24

估计资料不好找……找到后跟大家分享下哈，谢谢先……

月上百合 · 发表于 2010-8-23 22:05:39

恭喜愚人版主

楠族开心果 · 发表于 2010-8-24 08:30:55

这个估计很难找到吧，毕竟用的不多

千里 · 发表于 2010-8-24 08:57:57

我们公司的代码走查都是开发老大对程序员进行走查，重点查看代码规范、命名规范以及比较明显的代码错误。

测试新新手 · 发表于 2010-8-24 08:59:47

这个规范需要根据你们的开发规范来写,貌似国内代码走查做的很规范的很少见...

影儿2009 · 发表于 2010-8-24 09:19:04

走查：由文档作者逐步陈述文档内容，以收集信息并对内容达成共识。

主要的目的是学习、增加理解和发现缺陷。

内容：由作者主持开会；
         以情景、演示的形式和同行参加的方式进行；
         开放式模式；
         评审会议之前的准备、评审报告、发现的问题清单和记录员都是可选的；
         在实际情况下可以是非常正式的，也可以是非常不正式的。

xiaoli_javaY · 发表于 2010-8-24 09:25:05

回复个、下次继续来学习、好深奥、

xiaoyaoke · 发表于 2010-8-24 09:27:36

代码走查，属于静态的白盒测试，也就是让代码处于静态，然后阅读分析代码
首先，在执行代码走查之前要先定制rules，比如如果是C++的代码，就可以参考高效c++的50条啊之类的，然后去做

江潭素月 · 发表于 2010-8-24 13:49:20

原帖由千里于 2010-8-24 08:57 发表
我们公司的代码走查都是开发老大对程序员进行走查，重点查看代码规范、命名规范以及比较明显的代码错误。

我们老大比较忙，所以就让我们做了，可是我们测试本来技术就不怎么样。还要给开发人员检查代码逻辑是否正确是否有更好的解决办法是否能写成统一的处理方法

江潭素月 · 发表于 2010-8-24 13:50:51

原帖由 影儿2009 于 2010-8-24 09:19 发表
走查：由文档作者逐步陈述文档内容，以收集信息并对内容达成共识。

主要的目的是学习、增加理解和发现缺陷。

内容：由作者主持开会；
以情景、演示的形式和同行参加的方式进行；
开 ...

谢谢你。我们做走查的目的是给月底考核作参考，有没有遵守公司开发规范，代码写的如何，是不是写了重复代码等

江潭素月 · 发表于 2010-8-24 13:54:10

原帖由 xiaoyaoke 于 2010-8-24 09:27 发表
代码走查，属于静态的白盒测试，也就是让代码处于静态，然后阅读分析代码
首先，在执行代码走查之前要先定制rules，比如如果是C++的代码，就可以参考高效c++的50条啊之类的，然后去做

对，现在的问题是制定rules，该检查什么。在网上搜了些，待会贴出来，在里面挑挑吧。关于你说的高效c++的50条是什么东东，我咋没听过，我们是做java的

江潭素月 · 发表于 2010-8-24 13:55:11

代码走查的最主要的目的是为了发现程序中的逻辑错误，编程风格方面的错误可以通过风格检查的工具去检查。如下的检查单给代码走查的专家发现逻辑错误提供了一个很好的帮助。

　　序号检查项

　　1代码的注释与代码是否一致?注释是否是多余的?

　　2是否存在超过3层嵌套的循环与/或判断?

　　3变量的命名是否代表了其作用?

　　4所有的循环边界是否正确?

　　5所有的判断条件边界是否正确?

　　6输入参数的异常是否处理了?

　　7程序中所有的异常是否处理了?

　　8是否存在重复的代码?

　　9是否存在超过20行的方法?

　　10是否存在超过7个方法的类?

　　11方法的参数是否超过3个?

　　12是否有多种原因导致修改某个类?

　　13当发生某个功能变化时，是否需要修改多个类?

　　14代码中的常量是否合适?

　　15一个方法是否访问了其他类的多个属性?

　　16某几项数据是否总是同时出现，而又不是一个类的属性?

　　17switch语句是否可以用类来替代?

　　18是否有一类的职责很少?

　　19是否有一个类的某些属性或者方法没有被其他类所使用?

　　20在类的方法中是否存在如下的调用形式：a.b().c()?

　　21是否某个类的方法总是调用另外一个类的同名方法?

　　22是否某个类总是访问另外一个类的属性与方法?

　　23是否两个类完成了类似的工作，使用了不同的方法名，却没有拥有同一个父类?

　　24是否某个类仅有字段和简单的赋值方法与取值方法构成?

　　25是否某个子类仅使用了父类的部分属性或方法?

江潭素月 · 发表于 2010-8-24 13:55:44

1 尽可能不要使用import*
写的人很方便，读的人不爽，引入多余的类影响性能
2 尽量减少同名的类（如java.sql.Date，java.util.Date）
3 用StringBuffer代替String
不要这样 String str = (new String)V.Next();
也不要String Str = s+s1+s2
更不要for()｛
Str = "i"+Str;
｝
4不要在循环中反复定义创建变量
for()｛String str= （new String）v.next()；｝
5 不要在循环中使用复杂的计算
for(int i=0;i
6 不要有臃肿的判断逻辑
if(o!=null)｛
if(o.toString()!=null){
if(o.toString().equals(""))}
｝
7 合理使用equalIngoreCase
Str.equalIngoreCase("")能使用equals（“”）尽量使用，equalsIngorCase要进行循环比较，消耗Cpu时间
8浮点型要精确比较时不要使用＝＝，而如下进行
Math.abs(x-0.0)
9 可能重复执行的SQl语句尽量使用preparedStatment
10 Select语句中尽量不要使用相同的别名在Sybase 中会有问题
select a.Fid as Fid from...
11在sql中注意敏感的单词要回避使用
DB2 中id flag year month name state
Oracle 中number
Sybase中 count

江潭素月 · 发表于 2010-8-24 13:56:20

走查前准备
1 得到一份解释代码的最新的设计文档
2 代码解释时使用了严格的警告和错误检查参数并被解释通过
3 代码使用带ISO标准的xxxx编译器进行解释
程序结构
4 所有代码的结构清晰，具有良好的结构外观和整齐
5 所有的模块（函数和外部接口）定义清晰，模块分解清楚
6 所有的功能需求都明显的覆盖
7 高层设计独立于OS/环境
8 结构设计能够满足机能变更
9 代码体系结构描述了如何把代码重用到其他体系结构中
10 整个代码体系结构组合合理
11 所有主要的数据构造描述清楚，合理
12 模块中所有的数据结构都定义为局部的，并且通过定义好的函数进行访问
13 为外部定义了良好的函数接口
14 所有的接口模块化，因此修改时不影响其他代码模块
15 内存使用方法和内存管理策略描述清楚和正确
16 代码体系构架对空间和速度都已经进行考虑
17 提供了处理数据的策略
18 具有同一的错误处理策略
19 通过一套清晰的函数接口提供错误信息
目录文件组织
20 所有的文件名符合文件命名规范，见名知意
21 文件和模块分组清晰
22 每个文件有文件头和标准的习惯一致（描述文件的用途，作者，对外提供的函数）23 每个文件都组织的有序－文件头，类型定义，原型，函数
24 所有的代码行在80字符以内
25 每个程序文件都小于2000行
26 每个文件只包含一个完整功能模块的代码
函数组织
27 每个函数都有一个标准的函数头声明
28 函数组织：头，函数名，参数，函数体
29 函数定义符合ANSI或者用标准PERL的编译开关
30 每个函数都能够在最多2页纸可以打印
31 所有的变量声明每行只声明一个
32 所有的函数名都小于64个字符
33 每个函数之间都用2空行进行分开
代码组织
34 每行代码都小于80字符
35 所有的变量名都小于32字符
36 所有的行每行最多只有一句代码或一个表达式
37 复杂的表达式具备可读性
38 续行缩进
39 括号在合适的位置
40 每个顺序的小块用空行隔开
41 注解和代码对齐或接续在代码之后
移植性
42 代码与操作系统无关，不需要任何假设条件
函数
43 函数头清楚地描述函数和它的功能
44 代码中有相关注解
45 函数的名字清晰的定义了它的目标以及函数所做的事情
46 函数的功能清晰定义
47 函数中所有的部分都合理的组成函数，相关独立的语句组组成函数
48 函数高内聚只做一件事情，并做好
49 函数和其他代码松耦合
50 参数遵循一个明显的顺序；
51 所有的参数都被使用
52 函数的参数接口关系清晰
53 如果一个函数有返回值，在所有的出口都有返回值
54 函数使用了最少数目的return语句
55 函数的参数个数小于7个
56 所有的假设和接口清楚
57 使用的算法说明清楚
58 函数检查了输入数据的合法性
59 函数异常处理清楚
60 函数设计已经考虑了将来的变化
61 调试信息存在于代码中并容易激活
62 代码检查调用函数的返回值，参数和调用匹配
63 函数确保了没有影响函数外代码
64 递归定义了出口
65 递归局限于一个函数
66 堆栈大小支持递归调用的深度
数据类型与变量
67 数据类型存在数据类型解释
68 代码为每种可能改变数据类型的数据使用一个不同的类型
69 代码避免了重新定义预先定义的数据类型
70 数据结构简单以便降低复杂性
71 每一种变量分配了正确的长度、类型和存储空间
72 静态变量明确区分
73 所有的声明与编译器或具体的机器长度无关
74 每一个变量都初始化了
75 每一个变量都在接近使用它的地方才初始化
76 每一个变量都在将要使用它的时候才初始化
77 变量的命名完全、明确的描述了该变量代表什么
78 命名和现实生活中的事务接近而不仅仅是一个程序类型
79 同一种类型或指针命名的前缀指出类型或指针
80 命名不与标准库中的命名相冲突
81 程序没有使用特别的、易误解的、发音相似的命名
82 所有的变量都有最小的活动范围
83 所有的全局变量都描述清楚
84 使用函数访问取代全局数据的访问
85 所有的变量都用到了
86 存取数据的程序与全局数据的用法是兼容的
87 变量按照它的命名用途进行使用
特殊
88 所有的数组访问在它们的边界内
89 代码已经处理了-1错误
90 代码处理了指针异常
91 所有常量定义和使用替代代码中的数字
92 类型转换明确指明
其他注意项
93 代码与比较，计算变量的大小无关
94 代码与操作符的优先级无关
95 所有的表达式使用了正确的操作符
条件判断
96 条件检查和结果在代码中清晰
97 If/else 使用正确
98 普通的情况在if下处理而不是else
99 判断的次数降到最小
100 判断的次数不大于6次，无嵌套的if链
101 数字，字符，指针和0/NULL/FLSE 判断明确
102 boolen表达式表示清楚
103 最常用的情况最先判断
104 所有的情况都考虑
105 判断体足够短，以使得一次可以看清楚
106 嵌套层次小于3次
循环
107 循环体不为空
108 循环之前做好初始化代码
109 循环体能够一次看清楚
110 当有明确的多次循环操作，使用For循环
111 当有不明确的多次循环操作，while循环被使用
112 代码中不存在无穷次循环
113 循环的头部进行循环控制
114 循环索引具有有意义的命名
115 循环设计得很好它，只干一件事情
116 循环终止的条件清晰
117 循环体内的循环变量起到指示作用
118 循环嵌套的次数小于3次
输入输出
119 所有文件的属性描述清楚
120 所有OPEN/CREATE调用描述清楚
121 文件结束的条件进行检查
122 显示的文本无拼写和语法错误
注释
123 有一个简单的说明，用于描述代码的结构
124 每个文件和模块均以给予解释
125 源代码能够自我解释
126 每个人看到代码就能很快理解
127 解释说明代码功能，准确描述代码意义
128 解释不过于简单
129 注解清楚正确
130 注解为用户服务
131 所有的假设和限制进行注解
132 长的控制体结束，进行注解
总括
133 代码直观
134 代码中的用语符合广告用语，而不是技术化的描述
135 代码和设计文档对应
136 无用的代码已经删除
137 无用的注解已经删除

千里 · 发表于 2010-8-24 15:38:08

原帖由 江潭素月 于 2010-8-24 13:49 发表

我们老大比较忙，所以就让我们做了，可是我们测试本来技术就不怎么样。还要给开发人员检查代码逻辑是否正确是否有更好的解决办法是否能写成统一的处理方法

呵呵，你们老大有没有克林顿忙？他老人家还有时间交女朋友。经常看到的一个笑话
我们老大也很忙，不过他没叫我做过这样的事情，要给我做也会被我顶回去。
一个测试人员搞不定的事情，就算做了也是扯淡，做了也是装样子。

		自动登录	找回密码
密码			(注-册)加入51Testing

[原创] 请教前辈们在工作中代码走查是怎么做的

相关帖子

回复 3# 的帖子

在网上找的资料

网上找的资料

代码走查资料

站长推荐 /1