《软件过程与CMM》论文封面及评分表

学生学号0121110680524 论文成绩

武汉理工大学

课程论文

课程名称软件过程与CMM

论文题目提高代码质量

专业班级软件工程1102 学生姓名李曌

任课老师汪朝霞

2013 — 2014 学年第二学期

提高代码质量

班级：软件1102班姓名：李曌学号：0121110680524 组员：郭阳虎、张庆桔、李寿禹、李曌

摘要：如何提高代码质量，相信不仅是在座所有人苦恼的事情，也是所有软件

项目苦恼的事情。如何提高代码质量呢，我认为我们首先要理解什么是高质量的代码。本论文论述了提高代码质量的原因和方法，以及代码质量的要求。代码质量与软件质量的关系。软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。为提高代码质量分工协作是必不可少的。高质量程序设计是软件行业的薄弱环节，大部分企业为此付出了高昂的代价，只能通过大量的测试和改错来提高软件产品的质量。

1.软件质量

1.1软件质量定义

概括地说:软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。

具体地说:软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。

1.2软件质量的重要性

2003年8月14日，美国及加拿大部分地区发生了历史上最大的停电事故。当时的美国媒体曾怀疑“冲击波”病毒涉嫌造成大停电事故，一度引起“微软产品”以至IT信息安全的“信任恐慌”。

著名安全机构Security Focus的数据表明，2003年8月14日发生的美国及加拿大部分地区史上最大停电事故是由软件错误所导致。

Security Focus的数据表明，位于美国俄亥俄州的第一能源(FirstEnergy)公司下属的电力监测与控制管理系统“XA/21”出现软件错误，是北美大停电的罪魁祸首。根据第一能源公司发言人提供的数据，由于系统中重要的预警部分出现严重故障，负责预警服务的主服务器与备份服务器接连失控，使得错误没有得到及时通报和处理，最终多个重要设备出现故障导致大规模停电。预警系统崩溃后没有接收到更多的警报更没法向外传播，操作员并不知道预警系统已经失效，他们发现了部分异常情况，但因为没有看到预警系统的警报，而不知道情况有多么严重，以致一个小时后才得到控制站的指示。但此时没完没了的故障干扰已经让操作员反应不过来，无法控制整个局面。正常情况下，出现错误的网络会立即与其他网络分隔开来，这样一来错误就会被固定在一个地方，但是同样由于预警系统失灵，操作员没有做出应有的反应，最终使得错误蔓延，一发而不可收拾。

1.3代码质量对软件质量的贡献

⑴代码是软件产品中的重要部分

⑵代码质量反映软件质量

⑶其它非代码因素也起着关键作用

⑷文档（设计、帮助、用户手册等）

2.代码质量

2.1代码质量定义

代码的最终载体是软件产品(software);软件质量(software quality)最终体现于代码质量(code quality);符合用户需求,运行需求,性能优异,易维护,易扩展等

2.2代码的质量要求

•1可用性

•2健壮性

•3可测试性

•4可读性

•5可维护性

•6可扩展性

2.3如何保证代码质量

•保证可用性:功能测试,性能测试,可靠性测试

•保证可测试性:架构设计,子系统设计,模块设计,接口设计

•保证可读性:编程规范,代码风格

•保证可维护性/可扩展性:产品维护和扩展

•保证健壮性:压力测试,异常测试

3.高质量代码

3.1高质量代码的三要素

我们评价高质量代码有三要素：可读性、可维护性、可变更性。我们的代码要一个都不能少地达到了这三要素的要求才能算高质量的代码。

3.1.1可读性强

一提到可读性似乎有一些老生常谈的味道，但令人沮丧的是，虽然大家一而再，再而三地强调可读性，但我们的代码在可读性方面依然做得非常糟糕。由于工作的需要，我常常需要去阅读他人的代码，维护他人设计的模块。每当我看到大段大段、密密麻麻的代码，而且还没有任何的注释时常常感慨不已，深深体会到了这项工作的重要。由于分工的需要，我们写的代码难免需要别人去阅读和维护的。而对于许多程序员来说，他们很少去阅读和维护别人的代码。正因为如此，他们很少关注代码的可读性，也对如何提高代码的可读性缺乏切身体会。有时即使为代码编写了注释，也常常是注释语言晦涩难懂形同天书，令阅读者反复斟酌依然不明其意。针对以上问题，我给大家以下建议：

（1）不要编写大段的代码

如果你有阅读他人代码的经验，当你看到别人写的大段大段的代码，而且还不怎么带注释，你是怎样的感觉，是不是“嗡”地一声头大。各种各样的功能纠缠在一个方法中，各种变量来回调用，相信任何人多不会认为它是高质量的代码，但却频繁地出现在我们编写的程序了。如果现在你再回顾自己写过的代码，你会发现，稍微编写一个复杂的功能，几百行的代码就出去了。一些比较好的办法就是分段。将大段的代码经过整理，分为功能相对独立的一段又一段，并且在每段的前端编写一段注释。这样的编写，比前面那些杂乱无章的大段代码确实进步了不少，但它们在功能独立性、可复用性、可维护性方面依然不尽人意。从另一个比较专业的评价标准来说，它没有实现低耦合、高内聚。我给大家的建议是，将这些相对独立的段落另外封装成一个又一个的函数。

（2）释义名称与注释

我们在命名变量、函数、属性、类以及包的时候，应当仔细想想，使名称更加符合相应的功能。我们常常在说，设计一个系统时应当有一个或多个系统分析师对整个系统的包、类以及相关的函数和属性进行规划，但在通常的项目中这都非常难于做到。对它们的命名更多的还是程序员来完成。但是，在一个项目开始的时候，应当对项目的命名出台一个规范。譬如，在我的项目中规定，新增记录用new或add开头，更新记录用edit或mod开头，删除用del开头，查询用find 或query开头。使用最乱的就是get，因此我规定，get开头的函数仅仅用于获取类属性。

注释是每个项目组都在不断强调的，可是依然有许多的代码没有任何的注释。为什么呢？因为每个项目在开发过程中往往时间都是非常紧的。在紧张的代码开发过程中，注释往往就渐渐地被忽略了。利用开发工具的代码编写模板也许可以解决这个问题。

3.1. 2.可维护性

软件的可维护性有几层意思，首先的意思就是能够适应软件在部署和使用中的各种情况。从这个角度上来说，它对我们的软件提出的要求就是不能将代码写死。

（1）代码不能写死

我曾经见我的同事将系统要读取的一个日志文件指定在C盘的一个固定目录下，如果系统部署时没有这个目录以及这个文件就会出错。如果他将这个决定路径下的目录改为相对路径，或者通过一个属性文件可以修改，代码岂不就写活了。一般来说，我在设计中需要使用日志文件、属性文件、配置文件，通常都是以下几个方式：将文件放到与类相同的目录，使用ClassLoader.getResource()来读取；将文件放到classpath目录下，用File的相对路径来读取；使用web.xml或另一个属性文件来制定读取路径。

（2）预测可能发生的变化

除此之外，在设计的时候，如果将一些关键参数放到配置文件中，可以为软件部署和使用带来更多的灵活性。要做到这一点，要求我们在软件设计时，应当更多地有更多的意识，考虑到软件应用中可能发生的变化。比如，有一次我在设计财务软件的时候，考虑到一些单据在制作时的前置条件，在不同企业使用的时候，可能要求不一样，有些企业可能要求严格些而有些要求松散些。考虑到这种可能的变化，我将前置条件设计为可配置的，就可能方便部署人员在实际部署中进行灵活变化。然而这样的配置，必要的注释说明是非常必要的。

软件的可维护性的另一层意思就是软件的设计便于日后的变更。这一层意思与软件的可变更性是重合的。所有的软件设计理论的发展，都是从软件的可变更性这一要求逐渐展开的，它成为了软件设计理论的核心。

3.1.3可变更性

前面我提到了，软件的变更性是所有软件理论的核心，那么什么是软件的可变更性呢？按照现在的软件理论，客户对软件的需求时时刻刻在发生着变化。当软件设计好以后，为应对客户需求的变更而进行的代码修改，其所需要付出的代