代码走查检查单

实用标准文档

文案大全 软件产品WBS分解指南

一、概述

同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为“软件生命周期”。软件生命周期模型，通俗说就是，软件开发过程中所遵循的模式，即把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。

软件生命周期模型和项目开发过程有非常紧密关系，它是经过多次实践总结出来适合于不同项目使用的经典、有效的软件开发方法，它按照软件生命周期的各个阶段划分任务，依照一定的规则和步骤，有效地进行软件开发。

选用恰当的软件生命周期模型进行软件开发，可以提高产品质量；降低项目管理难度；缩短开发进度；便于项目状态跟踪；为过程改进和度量提供基线；改善组织级的过程弱势，提高过程能力成熟度级别。

为了便于分类汇总和统计各种生命周期模型的指标和数据，结合公司软件开发过程的实际，我们选择了常用的几种基本模型进行了描述，项目开发小组在进行项目策划时，可以根据模型的适用前提、优缺点和项目的实际需要进行选择，并在《项目实施计划》中，参加评审。

二、软件生命周期模型

常用的软件生命周期模型有：瀑布模型、迭代模型、增量模型、原型模型等。

以上所提到的件生命周期模型病不存在孰优孰劣的问题，每一种模型在实际工作中都有所应用。只要选择了最适合的，并按照此模型的流程来开发软件，都会取得成功。

需要强调的是，不管采用什么模型，项目实施中有四项活动是必不可少的——需求、设计、编码和测试。不管是有意识还是无意识，这些活动都会出现在项目过程中。这也是最重要的四项活动，其他的活动其实都是为这些活动服务的，不管是配置管理、风险管理，还是评审等等。

以下对各种常用的软件生命周期模型的设计思想、WBS划分（Work Breakdown Structure，即工作分解结构）、优缺点、使用范围进行分析。 实用标准文档

代码走查

一．代码走查的目的 1． 保证代码符合编码规范

2． 保证代码符合设计

3． 发现bug

4． 保证代码单元测试充分

5． 促进开发人员之间的交流，为代码的优秀程度的提高和开发人员编码技能的提高提供契机。

二．过程

每次迭代都要对修改过和新编的代码进行走查，走查的过程如下图：

否完成代码和测试代码，通过单元测试

开发人员告知可以走查

走查人员得出走查结论

通过否？

集成测试

需要修改代码

代码状态良好是

是走查人员和开发人员进行沟通

否

三．Checklist 说明：本checklist用于走查人员走查代码。开发人员用于自我检查的checklist可以参

照此checklist，依自身实际情况制定。 说明：本checklist应随着组织开发过程中出现的实际情况，对检查项具体内容进行增、

删、改，以使得此checklist更具效率，但要注意保持检查项数目的简洁。

类名：走查的类的名字

走查项摘要 走查项描述 走查结论

标准 代码符合C++编程规范 拷贝与赋值 无用的拷贝构造函数和赋值函数要显

示的禁止

注意自定义的拷贝构造函数和赋值函数是否对父类成员进行了构造和赋值

自定义的赋值函数应检查对自己的赋

值

析构函数 析构函数不能抛出异常

析构函数正确的释放了资源

析构函数是virtual？

const 函数参数能否加以const限制？ 成员函数能否加上const限制？

类型转换 强制类型转换要用C++的转换形式

窄化转换需用static_cast

变量 静态成员变量必须显示初始化

局部变量初始化后才使用

溢出 注意数据运算溢出的可能

临时变量 不要有对临时变量的非常量引用 布尔值 注意条件判断句里的赋值运算

异常 异常处理的代码运行过并测试过

发生异常时，资源正确释放，对象的状态得到必要恢复

异常的捕获使用引用

数组 注意数组的使用： 1． 数组中存放的对象不要多态使用

2． 删除用delete[]

3． 数组越界了么？

项目名称记录更新人记录更新时间

序号检查人检查日期模块名称检查文件数（个）代码总行数（LOC）花费工时（H）

150000250000350000编号

1-11-21-31-41-51-61-71-81-91-101-111-121-131-141-151-161-171-18

2-12-22-32-42-52-62-7

2.12.22.32.42.12.2代码走查记录跟踪单

不要过分依赖JVM的垃圾收集机制，因为你无法预测和知道JVM在什么时候运行GC。尽可能早的释放资源，不再使用的资源请立即释放。在不需要同步操作时避免使用同步操作类，尽量少用同步方法，尽量将同步最小化，即将同步步块或方法等。将参数或方法声明成final可提高程序响应效率，故此：注意绝对不要仅因为性能而将类、方法等声明成final，声明成final的类、方法一定要确信不再被继承或重完成相同或相近功能的菜单用横线隔开放在同一位置。避免在循环中频繁构建和释放对象。不再使用的对象应及时销毁。如无必要，不要序列化对象走查记录

4 其他在类、接口定义之前当对其进行注释，包括类、接口的目的、作用、功能、继承于何种父类，、示例程序等依据标准JavaDoc规范对方法进行注释，以明确该方法功能、作用、各参数含义以及返回值等应对重要的变量加以注释，以说明其含义等。应对不易理解的分支条件表达式加注释。不易理解的循环，应说明出口条件。过长的方法实现，应将其语句符合产品开发中心注释参考表内容描述

避免使用Vector和HashTable等旧的集合实现，这些实现的存在仅是为了与旧的系统兼容，而操作时会带来不必要的性能损失。3 性能与安全规范已检查异常必须捕捉并做相应处理，不能将已检查异常抛到系统之外去处理，需符合开发规范循环中必须有终止循环的条件或语句，避免死循环，需符合开发规范要求

注释必须使用中文及中文的标点符号。对类、方法、变量等的注释需要符合JavaDoc规范，对每个类、方法都应详细说明其功能、条式化注释，以使生成的JavaDoc易阅读和理解.在每个文件、包的头部都应该包含该文件的功能、作用、作者、版权以及创建、修改记录等2 注释规范异常类名由表示该异常类型的单词和Exception组成，如ActionException。异常实例一般使用e、ex等，在多个异常时使用该异常名或简写加E，Ex等组成符合开发规范4.7 命名约定表要求在导入包时当完全限制代码所使用的类的名字,尽量少用通配符的方式，但导入一些通用包，用通配符方式应该尽可能减小类与类之间耦合，所遵循的经验法则是：尽量限制成员函数的可见性。如果成为保护 (protected)；没必要保护 (protected)，就定义为私有 (private)。若没有足够理由，不要把实例或类变量声明为公有。公共和保护的可见性应当尽量避免，所有置成员函数（Getter、Setter）访问。符合开发规范中关于类与接口设计的原则要求。所有单词首字母大写。使用能确切反应该类、接口含义、功能等的词。一般采用名词采用完整的英文大写单词，在词与词之间用下划线连接，如：DEFAULT_VALUE对不易清楚识别出该变量类型的变量应使用类型缩写作其前缀，如字符串使用strXXX,boolea应采用完整的英文描述符命名组件（接口部件），遵循匈牙利命名法则一个集合，例如数组和矢量，应采用复数命名来表示队列中存放的对象类型。命名应采用完整单词的第一个字母应大写，适当使用集合缩写前缀方法的命名应采用完整的英文描述符，大小写混合使用：所有中间单词的第一个字母大写。方强烈动作色彩的动词检查项1 代码规范程序结构清晰，简单易懂，单个函数行数不得超过100行；使用可以准确说明变量/字段/类/接口/包等的完整的英文描述符避免使用长名字（最好不超过 25 个字母）采用大小写混合，提高名字的可读性。一般应该采用小写字母，但是类和接口的名字的首字母写。包名全部小写。0-1不符合项编号检查项编号检查模块编码者缺陷描述目录结构由用AntColony之newapp建立新项目时自动建立，符合开发规范中关于开发目录结构建立的要求走查模块

代码走查表代码走查的最主要的目的是为了发现程序中的逻辑错误，编程风格方面的错误可以通过风格检查的工具去检查。如序号检查项1、代码的注释与代码是否一致?是注释是否是多余的?2、是否存在超过3层嵌套的循环与/或判断?否3、变量的命名是否代表了其作用?是4、所有的循环边界是否正确?是5、所有的判断条件边界是否正确?是6、输入参数的异常是否处理了?是7、程序中所有的异常是否处理了?是8、是否存在重复的代码?否9、是否存在超过20行的方法?是10、是否存在超过7个方法的类?是11、方法的参数是否超过3个?否12、是否有多种原因导致修改某个类?是13、当发生某个功能变化时，是否需要修改多个类?否14、代码中的常量是否合适?是15、一个方法是否访问了其他类的多个属性?是16、某几项数据是否总是同时出现，而又不是一个类的属性?是17、switch语句是否可以用类来替代?是18、是否有一类的职责很少?是19、是否有一个类的某些属性或者方法没有被其他类所使用?否20、在类的方法中是否存在如下的调用形式：a.b().c()?否21、是否某个类的方法总是调用另外一个类的同名方法?22、是否某个类总是访问另外一个类的属性与方法?23、是否两个类完成了类似的工作，使用了不同的方法名，却没有拥有同一个父类?24、是否某个类仅有字段和简单的赋值方法与取值方法构成?25、是否某个子类仅使用了父类的部分属性或方法?检查的工具去检查。如下的检查单给代码走查的专家发现逻辑错误提供了一个很好的帮助。否