sonar监控java代码质量使用说明

sonar监控java代码质量使用说明
sonar监控java代码质量使用说明

一、sonar环境搭建

1、安装JDK-1.5以上版本。

2、安装mysql-5.x以上版本。

3、mysql新建数据库并增加权限

CREATE DATABASE sonar CHARACTER SET utf8 COLLATE utf8_general_ci;

GRANT all ON sonar.* TO sonar@localhost IDENTIFIED BY ‘sonar’; FLUSH PRIVILEGES ;

4、在sonar官网https://www.360docs.net/doc/d46039807.html,上下载并解压sonar-2.8.zip,不要放在中文目录下。

5、配置sonar-2.8\conf\sonar.properties文件。

1)配置启动的http端口

sonar.web.host: localhost

sonar.web.port: 9000

sonar.web.context: /

三句前本来被注释,取消注释

2)取消mysql连接的注释

#----- MySQL 5.x/6.x

# Comment the embedded database and uncomment the following properties to use MySQL. The validation query is optional.

sonar.jdbc.url:

jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=u tf8

sonar.jdbc.driverClassName: com.mysql.jdbc.Driver sonar.jdbc.validationQuery: select 1

运行sonar-2.8\bin\windows-x86-32\StartSonar.bat,打开相应的网页:

http://localhost:9000测试是否配置成功,这里的页面链接跟前头的http配置有关

二、配置sonar-runner

1、下载并解压sonar-runner.zip

官网下载网址:

https://www.360docs.net/doc/d46039807.html,/org/codehaus/sonar-plugins/sonar-runne r/1.0/sonar-runner-1.0.zip

2、环境变量,设置SONAR_RUNNER_HOME,在Path下添${SONAR_RUNNER_HOME}/bin (Unix) or %SONAR_RUNNER_HOME%/bin。

3、修改${SONAR_RUNNER_HOME}/conf/sonar-runner.properties文件,打开database connection, server URL的注释

命令行中输入sonar-runner –h查看是否配置成功

三、测试文件的配置

1、在每个项目的项目源文件目录下新建一个文件名为sonar-project.properties的文件,在文件中输入以下内容:

# required metadata

# My project------修改成你的项目名称

sonar.projectKey=my:project

sonar.projectName=My project

sonar.projectVersion=1.0

# path to source directories (required)

# srcDir1,srcDir2---------修改成你的源文件夹路径

sources=srcDir1,srcDir2

# path to test source directories (optional)

# testDir1,testDir2--------修改成你的测试文件夹路径

tests=testDir1,testDir2

# path to project binaries (optional), for example directory of Java #bytecode

# binDir--------修改成你的二进制文件夹路径

binaries=binDir

# path to project libraries (optional)

libraries=junit.jar

# advanced parameters

my.property=value

四、应用sonar监测代码质量

以上配置完成之后,就可以应用sonar来监测代码质量了。

1、先启动sonar用sonar-2.8\bin\windows-x86-32\ StartSonar.bat文件,这时可以查看sonar-2.8\logs\ sonar.log文件,看是否已经启动sonar

2、启动好sonar之后,接着在命令行中切换到项目文件的目录下,然后输入sonar-runner,等到运行结束后,进入到http://localhost:9000页面,查看代码的质量统计结果。

五、错误:https://www.360docs.net/doc/d46039807.html,ng.OutOfMemoryError处理方法:

在sonar-runner-1.0\bin\sonar-runner.bat文件中修改内存容量:

Set JAVA_OPTS=-Xms128m –Xmx512m %JAVA_OPTS%

编写高质量代码--Web前端开发修炼之道笔记

第一章从网站重构说起 打造高质量的前端代码,提高代码的可维护性——精简、重用、有序。 第二章团队合作 精一行,通十行。 增加代码可读性——注释。 重用性需提高,分为公共组件与私有组件,代码模块化。公共组件不能轻易修改,因为影响大,所以一般只提供“读”的权限。 磨刀不误砍柴工——前期的构思很重要。构思的主要内容包括规范的制定、公共组件的设计和复杂功能的技术方案等。一般来说,前期构思占整个项目30%~60%的时间都算是正常的。 第三章高质量的HTML

CSS只是web标准的一部分,在HTML、CSS、JS三大元素中,HTML才是最重要的,结构才是重点,样式是用来修饰结构的。正确的做法是,先确定HTML,确定语义的标签,再来选用合适的CSS。 判断标签语义是否良好的简单方法:去掉样式,看网页结构是否组织良好有序,是否仍然有很好的可读性。语义良好的网页去掉样式后结构依然很清晰。 “CSS裸体日”,2006.04.05第一届,从第三届开始改为4月9日。(设立目的就是为了提醒大家用合适的HTML标签的重要性) 一个语义良好的页面,h标签应该是完整有序没有断层的,也就是说要按照h1、h2、h3、h4这样的次序排下来,不要出现类似h1、h3、h4,漏掉h2的情况。 当页面内标签无法满足设计需要时,才会适当添加div和span等五语义标签来辅助实现。 第四章高质量的CSS 组织CSS的方法:base.css+common.css+page.css,在一般情况下任何一个网页的最终表现都是由这三者共同完成的,这三者不是并列结构,而是层叠结构。

base.css一般包括cssreset和通用原子类,比如设置一些常用的清除浮动、宽度、高度等class。可以参考一些前端框架,例如YUI、bootstrap等等。 拆分模块技巧:模块与模块之间尽量不要包含相同的部分,如果有相同部分,应将它们提取出来,拆分成一个独立的模块。模块应在保证数量尽可能少的原则下,做到尽可能简单,以提高重用性。 团队开发人员多,可在classname前加前缀。 如果不确定模块的上下margin特别稳定,最好不要将它们写到模块的类里,而是使用类的组合,单独为上下margin挂用于边距的原子类(例如mt10、mb20)。模块最好不用混用margin-top和margin-bottom,统一使用margin-top或margin-bottom。 低权重原则——避免滥用子选择器 普通标签权重1,class权重10,id权重100 为了保证样式容易被覆盖,提高可维护性,CSS选择符需保证权重尽可能低。 CSS sprite的最大好处是减少HTTP请求数,减轻服务器的压力,但它却需要付出“降低开发效率”和“增大维护难度”的代价。对于流量并不大的网站来说,CSS sprite带来的好处并不明显,而它付出的代价却很大,其实并不划算。所以是否使用CSS sprite主要取决于网站流量。 编码风格:推荐一行书写,能减少文件大小。(因为调试工具多,所以忽略易读性)Hack: A标签问题:

编写高质量Java代码

敏捷开发中编写高质量Java代码 敏捷开发的理念已经流行了很长的时间,在敏捷开发中的开发迭代阶段中,我们可以通过五个步骤,来有效的提高整个项目的代码质量。 Java项目开发过程中,由于开发人员的经验、Java代码编写习惯,以及缺乏统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。 如图1所示,敏捷开发过程经历需求调研,用例分析和用例分解,进入开发迭代阶段。在每个迭代过程中,可以采用以下步骤来保证和提高整个项目的代码质量:统一编码规范、代码样式;静态代码分析(staticcodereview);单元测试;持续集成;代码评审和重构 (Revi ew&Refactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。 图1.敏捷开发中的Java代码质量保证步骤 步骤一:统一编码规范、代码样式 规范统一的编码会增加项目代码的可读性和可维护性,但实际情况往往是项目组内的Java代码开发人员的编码风格常常各不相同,这可能是由于不同的经验习惯或者缺乏编码规范方面的学习造成的。这样一来,其他项目成员或者维护人员在阅读项目代码时就需要花费更多的时间来理解代码作者的意图,所以制定并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面: ◆一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。 ◆命名规则。例如包名、类名、变量、方法、接口、参数等命名规范 ◆文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。 ◆编程规范。例如异常、并发、多线程等方面的处理方式。 ◆其他规范。例如日志格式、属性文件格式,返回值和消息格式。

提高代码质量的三要素

提高面试代码质量的三要素 作者:baiyuzhong分类:管理阅读:7,387 次添加评论 作者总结自己多年面试他人以及被他人面试的经验,发现应聘者可以从代码的规范性、完整性和鲁棒性三个方面提高代码的质量。 程序员在职业生涯中难免要接受编程面试。有些程序员由于平时没有养成良好的编程习惯,在面试时写出的代码质量不高,最终遗憾地与心仪的公司和职位失之交臂。因此,如何在面试时能写出高质量的代码,是很多程序员关心的问题。 代码的规范性 面试官是根据应聘者写出的代码来决定是否录用一个应聘者的。应聘者首先要把代码写得规范,才可以避免很多低级错误。如果代码写得不够规范,会影响面试官阅读代码的兴致,至少印象分会打折扣。书写、布局和命名都决定着代码的规范性。 规范的代码书写清晰。绝大部分面试都要求应聘者在白纸或者白板上书写。由于现代人已经习惯了敲键盘打字,手写变得越发不习惯,因此写出来的字潦草难辨。虽然应聘者没有必要为了面试特意去练字,但在面试过程中减慢写字速度、尽量把每个字母写清楚还是很有必要的。不用担心没有时间去写代码。通常编程面试的代码量都不会超过

50行,书写不用花多少时间,关键是在写代码之前形成清晰的思路并能把思路用编程语言清楚地书写出来。 规范的代码布局清晰。平时程序员在集成开发环境如Visual Studio里面写代码,依靠专业工具调整代码的布局,加入合理的缩进并让括号对齐成对呈现。离开这些工具,应聘者就要格外注意布局问题。当循环、判断较多逻辑较复杂时,缩进的层次可能比较多。如果布局不够清晰,缩进也不能体现体现代码的逻辑,这样的代码将会让人头晕脑胀。 规范的代码命名合理。很多初学编程的人在写代码时总是习惯用最简单的名字来命名,变量名是i、j、k,函数名是f、g、h。由于这样的名字不能告诉读者对应的变量或者函数的意义,代码一长就会变得非常晦涩难懂。强烈建议应聘者在写代码时,用完整的英文单词组合命名变量和函数,比如函数需要传入一个二叉树的根结点作为参数,则可以把该参数命名为BinaryTreeNode* pRoot。不要因为这样会多写几个字母而觉得麻烦。如果一眼能看出变量、函数的用途,应聘者就能避免自己搞混淆而犯一些低级的错误。同时合理的命名也能让面试官一眼就能读懂代码的意图,而不是让他去猜变量到底是数组中的最大值还是最小值。 代码的完整性

敏捷开发中编写高质量Java代码+

敏捷开发中编写高质量Java代码收藏 敏捷开发的理念已经流行了很长的时间,在敏捷开发中的开发迭代阶段中,我们可以通过五个步骤,来有效的提高整个项目的代码质量。 Java项目开发过程中,由于开发人员的经验、Java代码编写习惯,以及缺乏统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。 如图1所示,敏捷开发过程经历需求调研,用例分析和用例分解,进入开发迭代阶段。在每个迭代过程中,可以采用以下步骤来保证和提高整个项目的代码质量:统一编码规范、代码样式;静态代码分析(staticcodereview);单元测试;持续集成;代码评审和重构(Review&Refact or)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。 图1.敏捷开发中的Java代码质量保证步骤

步骤一:统一编码规范、代码样式 规范统一的编码会增加项目代码的可读性和可维护性,但实际情况往往是项目组内的Java代码开发人员的编码风格常常各不相同,这可能是由于不同的经验习惯或者缺乏编码规范方面的学习造成的。这样一来,其他项目成员或者维护人员在阅读项目代码时就需要花费更多的时间来理解代码作者的意图,所以制定并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面: ◆一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。 ◆命名规则。例如包名、类名、变量、方法、接口、参数等命名规范 ◆文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。 ◆编程规范。例如异常、并发、多线程等方面的处理方式。 ◆其他规范。例如日志格式、属性文件格式,返回值和消息格式。 项目的编码规范可以参考已有的一些Java编程规范书籍和其他相关资料并结合项目的本身来制定,可供参考的书籍有《Java编程风格》(英文书名为:TheElementsofJavaStyle)。编码规范要形成文档,而且要简洁明了,并组织项目成员一起学习,确保所有成员正确理解所有条目。 一旦编码规范确定,就可以利用Eclipse自身提供的功能来控制代码样式和格式。具体做法是,点击Eclipse的Windows->Preference菜单项,在打开的Preferences对话框的左侧栏中找到Java节点下的子项CodeStyle(如图2),该项和它的子项允许您对Java代码的样式进行控制。

如何提高代码质量

我们评价高质量代码有三要素:可读性、可维护性、可变更性。我们的代码要一个都不能少地达到了这三要素的要求才能算高质量的代码。 今天这堂培训课讲什么呢?我既不讲Spring,也不讲Hibernate,更不讲Ext,我不讲任何一个具体的技术。我们抛开任何具体的技术,来谈谈如何提高代码质量。如何提高代码质量,相信不仅是在座所有人苦恼的事情,也是所有软件项目苦恼的事情。如何提高代码质量呢,我认为我们首先要理解什么是高质量的代码。 高质量代码的三要素 我们评价高质量代码有三要素:可读性、可维护性、可变更性。我们的代码要一个都不能少地达到了这三要素的要求才能算高质量的代码。 1. 可读性强 一提到可读性似乎有一些老生常谈的味道,但令人沮丧的是,虽然大家一而再,再而三地强调可读性,但我们的代码在可读性方面依然做得非常糟糕。由于工作的需要,我常常需要去阅读他人的代码,维护他人设计的模块。每当我看到大段大段、密密麻麻的代码,而且还没有任何的注释时常常感慨不已,深深体会到了这项工作的重要。由于分工的需要,我们写的代码难免需要别人去阅读和维护的。而对于许多程序员来说,他们很少去阅读和维护别人的代码。正因为如此,他们很少关注代码的可读性,也对如何提高代码的可读性缺乏切身体会。有时即使为代码编写了注释,也常常是注释语言晦涩难懂形同天书,令阅读者反复斟酌依然不明其意。针对以上问题,我给大家以下建议: 1)不要编写大段的代码 如果你有阅读他人代码的经验,当你看到别人写的大段大段的代码,而且还不怎么带注释,你是怎样的感觉,是不是“嗡”地一声头大。各种各样的功能纠缠在一个方法中,各种变量来回调用,相信任何人多不会认为它是高质量的代码,但却频繁地出现在我们编写的程序了。如果现在你再回顾自己写过的代码,你会发现,稍微编写一个复杂的功能,几百行的代码就出去了。一些比较好的办法就是分段。将大段的代码经过整理,分为功能相对独立的一段又一段,并且在每段的前端编写一段注释。这样的编写,比前面那些杂乱无章的大段代码确实进步了不少,但它们在功能独立性、可复用性、可维护性方面依然不尽人意。从另一个比较专业的评价标准来说,它没有实现低耦合、高内聚。我给大家的建议是,将这些相对独立的段落另外封装成一个又一个的函数。

软件代码质量控制

也许你是一位项目经理,也许你是一位项目骨干成员,或者开发小组长。在我发表“如何提高代码质量”的这一系统文章后,有许多网友都向我抱怨,说他无法把握整个项目组成员的代码质量。我想,这也是所有项目组普遍存在的问题吧,它通常表现为以下几个问题: 软件项目普遍存在的问题 1)新手。任何项目组成员都不可避免地出现新手,他们往往是刚刚从大学毕业的学生。这些新手由于软件开发时间太短,往往技术不成熟,没有形成良好的开发习惯,所以编写代码质量较差,问题很多。他们常常成为项目组的“鸡肋”,用多了项目质量无法得到保证,不用则又人手不够。 2)人员变动。一个维护时间稍长一点儿的软件项目,人员变动是在所难免的。老员工被调动到其它项目去了,由新员工来接替他们的工作。在我的项目组中,人员调动达到了90%,唯一没有调走的就是我自己。新员工在接替老员工进行代码维护,甚至继续进行新的开发的时,由于对原有代码以及设计思路理解的偏差,也会出现大量的低劣代码。 3)不规范的代码编写。即使除去以上两个问题的影响,项目组成员编写的代码同样会出现问题。在项目开发之初,我们往往会制定一个代码编写的规范,但在项目开发过程中,许多成员往往会忽视这些代码规范而进行随意的编写。随意地代码编写会降低代码的可读性、可维护性和易变更性。那么,我们应当采用什么样的管理措施,保证代码的规范,提高代码的质量呢? 以上问题,也是我在项目开发中不断摸索和思考的问题,而一些有经验的项目经理给出了他们的解决之道,那就是“代码复查”。 什么是代码复查 代码复查(Code Review),又叫“代码审查”,其基本思想就是,在开发人员编写完自己的代码后,由其他人来复查他写的代码,从而有效地发现代码中存在的缺陷。代码复查的一个基本理论就是,当我们越早发现代码存在的缺陷,我们解决缺陷的代价就越低。代码复查往往分成以下一个方面进行审查:1)代码风格。在项目开发之初,我们往往会制定一个代码编写的规范,实际上,这个代码规范就包含了整个项目组的代码风格。由于软件开发人员的设计习惯不同,如果不统一代码风格,一个项目中的代码将五花八门,如变量和常量的命名、接口与实现类的注释、何时回车、怎样缩进等等。一个五花八门的设计风格,必将为日后的维护与改进带来困难。我们通过代码复查,一方面督促开发人员按照规范编写代码,另一方面也使开发人员自身形成良好的编程习惯。代码

如何提高代码质量

一、提高编码质量的重要性: 代码是写给别人看,给别人用的。 一要考虑代码移交给别人维护;二是要考虑代码的各模块给别人复用。 二、执行的质量标准: 可读性、可维护性、易用性、可扩展性、可复用性、鲁棒性 1、可读性、可维护性 初级要求:别人拿到你的代码,没有阅读障碍,不需要向你请教也能看懂。 高级要求:别人可以花很少的时间看懂。 1)注释 a、文件注释:这个文件是干嘛的 b、模块注释:这个模块完成什么功能。对于嵌入式中资源的驱动,尽量描绘出 资源的信息。譬如flash驱动,应该描述出基地址、长度、扇区数、扇区的 基地址等。 c、逻辑注释:这个复杂的逻辑是如何实现的 d、函数注释:这个函数完成什么功能,该怎么用 e、功能块注释:这个函数内的这段话,要实现什么功能 f、变量注释:这个变量的作用 g、其它注释:宏定义、结构体、枚举、联合体等 2)版式 致力于让阅读更轻松 a、适量的使用空行,隔开不同的功能块 b、长行拆分 c、对齐 d、一行定义一个变量 e、尽量使用括号、花括号 f、变量的初始化 g、函数不要太长,长了之后考虑是否可以拆分 3)命名规则(风格) 从名字间获取最大量的信息,降低阅读障碍,提高阅读速度。 a、命名风格统一 b、顾名思义,名字应能准确反映出意思 c、命名要能明确区分出不同的类别:函数、宏、结构体、常量、全局变量、静 态变量、常量。 d、匈牙利命名法:强调变量的类型。 e、文件命名风格也要统一 4)模块化、层次清楚 阅读时,首先能总览全局,知道都有什么;对任何关注的局部,可以直接展开。 a、希望它是一棵树,不是一张蜘蛛网。 低耦合。 b、一棵面向对象的树

高质量代码三要素

高质量代码的三要素 我们评价高质量代码有三要素:可读性、可维护性、可变更性。我们的代码要一个都不能少地达到了这三要素的要求才能算高质量的代码。 1.可读性强 一提到可读性似乎有一些老生常谈的味道,但令人沮丧的是,虽然大家一而再,再而三地强调可读性,但我们的代码在可读性方面依然做得比较糟糕。每当我看到大段大段、密密麻麻的代码,而且还没有任何的注释时常常感慨不已,深深体会到了这项工作的重要。由于分工的需要,我们写的代码难免需要别人去阅读和维护的。而对于许多程序员来说,他们很少去阅读和维护别人的代码。正因为如此,他们很少关注代码的可读性,也对如何提高代码的可读性缺乏切身体会。有时即使为代码编写了注释,也常常是注释语言晦涩难懂形同天书,令阅读者反复斟酌依然不明其意。针对以上问题,我给大家以下建议: 1)不要编写大段的代码 如果你有阅读他人代码的经验,当你看到别人写的大段大段的代码,而且还不怎么带注释,你是怎样的感觉,是不是“嗡”地一声头大。各种各样的功能纠缠在一个方法中,各种变量来回调用,相信任何人都不会认为它是高质量的代码,但却频繁地出现在我们编写的程序了。如果现在你再回顾自己写过的代码,你会发现,稍微编写一个复杂的功能,几百行的代码就出去了。一些比较好的办法就是分段。将大段的代码经过整理,分为功能相对独立的一段又一段,并且在每段的前端编写一段注释。这样的编写,比前面那些杂乱无章的大段代码确实进步了不少,但它们在功能独立性、可复用性、可维护性方面依然不尽人意。从另一个比较专业的评价标准来说,它没有实现低耦合、高内聚。我给大家的建议是,将这些相对独立的段落另外封装成一个又一个的函数。 许多大师在自己的经典书籍中,都鼓励我们在编写代码的过程中应当养成不断重构的习惯。我们在编写代码的过程中常常要编写一些复杂的功能,起初是写在一个类的一个函数中。随着功能的逐渐展开,我们开始对复杂功能进行归纳整理,整理出了一个又一个的独立功能。这些独立功能有它与其它功能相互交流的输入输出数据。当我们分析到此处时,我们会非常自然地要将这些功能从原函数中分离出来,形成一个又一个独立的函数,供原函数调用。在编写这些函数时,我们应当仔细思考一下,为它们取一个释义名称,并为它们编写注释(后面还将详细讨论这个问题)。另一个需要思考的问题是,这些函数应当放到什么地方。这些函数可能放在原类中,也可能放到其它相应职责的类中,其遵循的原则应当是“职责驱动设计”(后面也将详细描述)。 在编写代码的过程中,通常有两种不同的方式。一种是从下往上编写,也就是按照顺序,每分出去一个函数,都要将这个函数编写完,才回到主程序,继

如何提高代码质量(管理篇):代码复查

如何提高代码质量(管理篇):代码复查 也许你是一位项目经理,也许你是一位项目骨干成员,或者开发小组长。在我发表“如何提高代码质量”的这一系统文章后,有许多网友都向我抱怨,说他无法把握整个项目组成员的代码质量。我想,这也是所有项目组普遍存在的问题吧,它通常表现为以下几个问题: 软件项目普遍存在的问题 1)新手。任何项目组成员都不可避免地出现新手,他们往往是刚刚从大学毕业的学生。这些新手由于软件开发时间太短,往往技术不成熟,没有形成良好的开发习惯,所以编写代码质量较差,问题很多。他们常常成为项目组的“鸡肋”,用多了项目质量无法得到保证,不用则又人手不够。 2)人员变动。一个维护时间稍长一点儿的软件项目,人员变动是在所难免的。老员工被调动到其它项目去了,由新员工来接替他们的工作。在我的项目组中,人员调动达到了90%,唯一没有调走的就是我自己。新员工在接替老员工进行代码维护,甚至继续进行新的开发的时,由于对原有代码以及设计思路理解的偏差,也会出现大量的低劣代码。 3)不规范的代码编写。即使除去以上两个问题的影响,项目组成员编写的代码同样会出现问题。在项目开发之初,我们往往会制定一个代码编写的规范,但在项目开发过程中,许多成员往往会忽视这些代码规范而进行随意的编写。随意地代码编写会降低代码的可读性、可维护性和易变更性。那么,我们应当采用什么样的管理措施,保证代码的规范,提高代码的质量呢? 以上问题,也是我在项目开发中不断摸索和思考的问题,而一些有经验的项目经理给出了他们的解决之道,那就是“代码复查”。 什么是代码复查 代码复查(Code Review),又叫“代码审查”,其基本思想就是,在开发人员编写完自己的代码后,由其他人来复查他写的代码,从而有效地发现代码中存在的缺陷。代码复查的一个基本理论就是,当我们越早发现代码存在的缺陷,我们解决缺陷的代价就越低。代码复查往往分成以下一个方面进行审查: 1)代码风格。在项目开发之初,我们往往会制定一个代码编写的规范,实际上,这个代码规范就包含了整个项目组的代码风格。由于软件开发人员的设计习惯不同,如果不统一代码风格,一个项目中的代码将五花八门,如变量和常量的命名、接口与实现类的注释、何时回车、怎样缩进等等。一个五花八门的设计风格,必将为日后的维护与改进带来困难。我们通过代码复查,一方面督促开发人员按照规范编写代码,另一方面也使开发人员自身形成良好的编程习惯。代码风格的审查,由于内容比较单一,我们常常可以通过一些代码复查的工具来自动完成,提高复查的效率。 2)重大缺陷。在一些关于代码复查的文章中,列出了一个常常的单子,描述了代码复查应当着重注意的重大缺陷,它们包括:存在SQL注入、易受跨站点脚本攻击、缓存区溢出、托管代码等等。项目组可以不断积累重大缺陷的审查项目,并在每次审查中逐一检查。重大缺陷审查是一个繁琐而细致的工作,如果能编写或使用一些审查软件,可以大大提高我们的审查效率。 3)设计逻辑与思路的审查。我认为,这部分的审查是代码复查中最核心、最有价值的部分。代码风格与重大缺陷的审查,虽然重要但简单而机械,可以通过软件自动检查;而设计逻辑与思路的审查,却是复杂而

敏捷开发中高质量Java代码开发实践

本文将介绍在敏捷开发过程中如何通过采取一系列的步骤来保证和提高整个项目的代码质量,阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,成就高质量的代码。 概述 Java 项目开发过程中,由于开发人员的经验、代码风格各不相同,以及缺乏统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。本文将结合敏捷开发周期短,变化快等特点,介绍如何通过在开发过程中采取一系列步骤来保证和提高整个开发团队的代码质量,并阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,成就高质量的代码,减少测试的投入,并促进整个团队的技能提高,最终提高开发效率和质量。 如图 1 所示,敏捷开发过程经历需求调研,用例分析和用例分解,进入开发迭代阶段。在每个迭代过程中,可以采用以下五个步骤来保证和提高整个项目的代码质量:统一编码规范、代码样式;静态代码分析(static code review);单元测试;持续集成;代码评审和重构(Review & Refactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。 图 1. 敏捷开发中的 Java 代码质量保证步骤 步骤一:统一编码规范、代码样式

规范统一的编码会增加项目代码的可读性和可维护性,但实际情况往往是项目组内的 Java 代码开发人员的编码风格常常各不相同,这可能是由于不同的经验习惯或者缺乏编码规范方面的学习造成的。这样一来,其他项目成员或者维护人员在阅读项目代码时就需要花费更多的时间来理解代码作者的意图,所以制定并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面: ?一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。 ?命名规则。例如包名、类名、变量、方法、接口、参数等命名规范 ?文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。 ?编程规范。例如异常、并发、多线程等方面的处理方式。 ?其他规范。例如日志格式、属性文件格式,返回值和消息格式。 项目的编码规范可以参考已有的一些 Java 编程规范书籍和其他相关资料并结合项目的本身来制定,可供参考的书籍有《 Java 编程风格》(英文书名为:The Elements of Java Style)。编码规范要形成文档,而且要简洁明了,并组织项目成员一起学习,确保所有成员正确理解所有条目。 一旦编码规范确定,就可以利用 Eclipse 自身提供的功能来控制代码样式和格式。具体做法是,点击 Eclipse 的 Windows -> Preference 菜单项,在打开的 Preferences 对话框的左侧栏中找到 Java 节点下的子项 Code Style(如图 2),该项和它的子项允许您对 Java 代码的样式进行控制。 图 2. Eclipse 代码样式设置窗口

如何评价代码质量

如何评价代码质量 我们平时买东西的时候,要看一看东西的质量怎么样,如颜色好看否、样式时尚否、经久耐用否,然后再决定买不买。软件作为一种商品,也存在质量高低之分,从哪些方面来评价软件的质量状况呢? 代码是软件的元素,软件是产品的灵魂,所以评价代码质量的标准源于评价产品质量的标准。 产品服务于用户,用户的评价体现了代码的质量,用户在使用软件产品时的三种不同倾向或观点:产品运行、产品修改和产品转移。 由图可见,评价代码质量的主要指标: 1. 正确性(Correctness) 系统满足规格说明和用户目标的程度,即在预定环境下能正确地完成预期功能的程度。 如软件有没有按照需求规格来完成,计算出的结果是否正确,计算结果是否精确。 2. 健壮性/鲁棒性(Robustness) 健壮性是指在异常情况下(如硬件发生故障、输入的数据无效或操作错误等),软件能够正常运行的能力。 健壮性有两层含义:一是容错能力,二是恢复能力。 容错是指发生异常情况时系统不出错误的能力,对于应用于航空航天、武器、金融等领域的这类高风险系统,容错设计非常重要。 而恢复则是指软件发生错误后(不论死活)重新运行时,能否恢复到

没有发生错误前的状态的能力。 例如:因输入数据不正确,引起系统异常,这是容错能力不高引起的健壮性问题;操作系统死机了,重启后能够正常使用,说明具有一定恢复能力,具有一定的健壮性;数据库发生故障后,再次启动时一般能够恢复到正常的状态,恢复能力比较好。 3. 可靠性(Reliability) 软件系统在一定的时间内无故障运行的能力。 可靠性是一个与时间相关的属性,指的是在一定环境下,在一定的时间段内,程序不出现故障的概率,因此是一个统计量,通常用平均无故障时间(MTTF, mean-time to fault)来衡量。 可靠性不同于正确性和健壮性,软件可靠性问题通常是由于设计中没有料到的异常和测试中没有暴露的代码缺陷引起的。 例:由于某个地方数据库连接没有释放,在长时间运行的时候,出现活动的数据库连接数过多,造成系统越来越慢,甚至系统停止服务。 4. 性能(Performance) 性能是指软件及时提供相应服务的能力。具体而言,性能包括速度、吞吐量和持续高速性三方面的要求: 速度往往通过平均响应时间来度量; 吞吐量通过单位时间处理的交易数来度量; 持续高速性是指保持高度处理速度的能力。 效率(Efficiency)指软件对CPU处理能力和存储能力这两大类计算机资源的使用效率。效率和性能反映了同一问题的“表”、“里”,性能 为“表”,效率为“里”。 如系统运算一个报表,需要很长时间,这就是性能问题。 5. 安全性(Security) 指软件同时兼顾向合法用户提供服务,以及阻止非授权使用软件及资源的能力。 安全性既属于技术问题又属于管理问题。一般地,如果黑客为非法入侵花费的代价(考虑时间、费用、风险等多种因素)高于得到的好处,那么这样的系统就可以认为是安全的。 例:有人可以访问非授权的资源,这就是安全性问题。 6. 易用性(Usability) 易用性是指用户使用软件的容易程度。 软件的易用性要让用户来评价。 例:对于一般用户而言,Windows的易用性比Linux的高。 7. 可用性(Availability)

01-软件高质量代码体系最佳实践 1天

软件高质量代码体系最佳实践 一、为什么需要该课程 软件质量,不但依赖于架构,设计以及项目管理,而且与代码质量紧密 相关.这一点,无论你使用什么开发技术,都不得不承认.代码是程序员沟 通最直接的手段,代码是技术交流的手段,代码是需求交流的途径。重视代码,回归本源,曾经我们远离代码,谈架构设计,谈UML,谈开发流程。如今我们落地,找回软件的本源,彻彻底底看清代码、深入思考代码。那些一流的研发中心非常重视代码,Facebook就有经典的Code wins arguments (代码赢得争论)。在Facebook 做 code review时间大约占50%,管理者对代码质量负有一定责任。甚至代码质量高于一切:Facebook Code review 是重点KPI考核的对象,实行连坐制,如果因为代码质量问题,那么产生的KPI责任包括领导30%、程序员50%、审核人员20%。 但是我们的管理者经常听到开发人员这样抱怨:“不能再增加功能了!我们得停下来重写代码。软件代码一团糟,就像纸糊的老虎,根本应付不了持续增加的用户需求。我们实在维护不下去了!最好推倒重写吧” 这一幕在很多公司上演过,现在依然在不断重演。一旦公司陷入这种困境,以前版本的开发者往往沦为替罪羊。新的开发者一般就会骂前人怎么写这么烂的代码。他们准备推倒重来,准备重写系统。在重写代码的过程中,用户无法看到产品的任何改进。你可能认为重写代码至多也就几个月,但是实际花费的时间无一例外要多得多。你只能坐在一旁,眼睁睁看着用户投奔竞争对手,而这个时候,竞争对手恰恰在不断地改进产品。 我们研发中心有一个理念”代码是债务而不是资产”。最开始,团队会编写代码,做出产品,并用它来赚钱,但是,之后团队应该尽可能地寻找减少代码的方法和使代码尽量整洁,从而降低成本。软件界有一个真理,你拥有的代码越多,维护代码所要付出的成本就越高。如果你的代码结构越好,你做了越多的单元测试,你的代码质量越好、越小、耦合越松,那么添加新代码所需要付出的成本就越少。因此大师 Craig Larman说: “最好维护的代码就是没有代码,好的程序员的代码产量是负的,因为他通过减少代码来增加功能”。对比现实中,很多人以为,LOC(line of code)越多的feature越大,写LOC越多的程序员越牛。这其实是极其错误的观念. 因此我们必须有全面的管理制度让我们保持代码少而整洁。所以Michael Feathers认为"未来属于知道如何有策略地删除代码的公司”。持有代码的成本要比我们想象的大。意识到这一点的公司更具有竞争优势。

开发人员质量考核办法

代码质量考核办法 1.开发人员代码考核办法 1.1.目的 开发人员代码考核主要是针对在内部开发阶段代码质量进行考核,目的是提升开发人员的质量意识,提高公司代码开发质量。 1.2.考核内容 考核阶段主要是在公司内部的开发阶段(即在提交用户前),主要考核的内容为:提交测试被打回、缺陷密度,BUG收敛率等方面。在项目执行的每轮测试给出每个开发人员的缺陷密度、BUG收敛率。在内部封版结束后质量保证部出每个开发人员BUG密度总和,平均BUG收敛率。 数据分析在每轮测试完成和每项目封版结束及时给出,开发人员3天内可以申述,针对有争议的地方进行讨论。 1.2.1.提交测试被打回 提交测试因提交的版本有严重质量问题被打回,出现这种情况会影响整体工作进度,并浪费开发和测试人员的时间。部署环境问题导致问题不在此范围内。 考核标准 每次扣除月绩效0.1,项目奖金绩效0.1 1.2.2.缺陷密度 缺陷密度=缺陷总数/功能点总数 缺陷总数,需剔除原型类BUG、建议性BUG。 功能点数为加权平均后的功能点数,计算规则详见后面2计算规则说明考核标准

缺陷密度量化标准(需试运行阶段采集,CMM 3级标准:每功能点5个) X~XX个奖励月绩效0.05,项目奖金绩效0.1(需讨论) X~XX个合格(平均水平) X~XX个扣除月绩效0.05,项目奖金绩效0.1(需讨论) X~XX个扣除月绩效0.1,项目奖金绩效0.2 (需讨论) 1.2.3.BUG收敛率 BUG收敛率=(前一轮bug数量—本轮bug数量)/前一轮bug数量 测试人员区分是开发修改引起的bug,还是测试未测试出来的bug。前一轮未测出的bug 不在统计范围。 考核标准 BUG收敛率<=X%(需试运行阶段采集) X%~XX% 奖励月绩效0.05,项目奖金绩效0.1(需讨论) X%~XX% 合格(平均水平) X%~XX% 扣除月绩效0.05,项目奖金绩效0.1(需讨论) X%~XX% 扣除月绩效0.1,项目奖金绩效0.2 (需讨论) 1.3.考核方式 1.3.1.部门工作绩效考核 按照考核内容的项目绩效考核方法扣除相应绩效。 1.3. 2.项目绩效考核 项目结项时按照考核内容的项目绩效考核方法扣减相应比例 1.3.3.年度考核 代码考核可以作为年度考核的依据。 每个开发人员在年度出现三次因代码质量问题(即三次因代码质量引起扣除绩效)可以

如何改善团队代码质量

如何改善团队代码质量 对于一个以软件开发为主的企业,软件代码的质量相当重要,但在实际的工作中,对于客户和管理者而言,软件代码的质量又往往不被看到或重视,这里存在一个“冰山理论”,对于软件产品而言,那些能被客户或管理者感知的软件功能只是庞大的软件代码这座“冰山”的一角,所以我们经常形成这样的感叹,在如此紧张的项目进度下,还花时间去改善代码质量,怎么能做得到呢? 其实改善代码质量说难很难,说简单呢也简单。说它难,难在改善代码质量,最终离不开程序员本身的努力;说他简单,简单在改善代码质量的方法,途径还是很多的,只要我们肯去做,总会有或多或少的成效。 改善代码质量,首先要提高程序员的质量意识,让每个程序员知道什么是高质量的代码,如何编写高质量的代码。达到这一点,可以通过不断的培训,提高程序员的编程技能,这个过程是一个多赢的过程,程序员编程技能提高了,个人得到成长;程序质量提高了,产品在开发过程中出现的问题会减少,项目进度更容易控制;程序质量提高了,产品可以更加稳定,客户会更满意,等等,总之,这是一切良性循环的开始。 那什么样的代码才是高质量的代码呢?先引用一些专家的观点说明: A.我喜欢优雅和高效的代码。代码逻辑应当直截了当,叫缺陷难以隐藏;尽量减少依 赖关系,使之便于维护;依据某种分层战略完善错误处理代码;性能调制最优,省 得引诱别人做没有规矩的优化,搞出一堆混乱来。整洁的代码只做好一件事。 —— Bjarne Stroustup B.整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的 意图,充满了干净利落的抽象和直截了当的控制语句。—— Grady Booch C.我可以列出我留意到的整洁代码的所有特点,但其中有一条是根本性的。整洁的代 码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地。代码作者什么 都想到了,如果你企图改进它,总会回到原点。—— Michael Feathers 那怎样才能做到上面所说的结果呢?下面给大家概括一些编写高质量代码的方法。 (一)使用有意义的命名 a)命名要名副其实。 变量,函数或类的名称应该告诉你它为什么存在,它做什么事,应该怎么用,如果这些命名还需要用注释来补充,那就不算是名副其实。比如以下代码: int d;//消逝的时间,以日记 b)避免误导。 比如,别用accountList来指一组账号,除非它真的是List类型。 c)做有意义的区分。 废话是一种典型的没有意义的区分,比如你有一个Product类,如果还有一个ProductInfo 类或ProductData类,那它们的名称虽然不同,意思确无区别。

代码整洁之道-卓越软件代码质量体系最佳实践

代码整洁之道-卓越软件代码质量体系最佳实践 课程简介: 管理者最担心听到开发人员这样抱怨:“不能再增加功能了!我们得停下来重写代码。代码库一团糟,就像纸糊的老虎,根本应付不了持续增加的用户。我们维护不下去了!” 这一幕在很多公司上演过,现在依然在不断重演。一旦公司陷入这种困境,以前版本的开发者往往沦为替罪羊。新的开发者一般就会骂前人怎么写这么烂的代码。他们准备推倒重来,准备重写系统。在重写代码的过程中,用户无法看到产品的任何改进。你可能认为重写代码至多也就几个月,但是实际花费的时间无一例外要多得多。你只能坐在一旁,眼睁睁看着用户投奔竞争对手,而这个时候,竞争对手恰恰在不断地改进产品。 因此我们认为软件质量,不但依赖于架构及项目管理,而且与代码质量紧密相关。这一点,无论是敏捷开发流派还是传统开发流派,都不得不承认。干净整洁的代码,既在质量上较为可靠,也为后期维护、升级,架构演进奠定了良好基础。在最近几年的业界,大家都把精力花费在了软件需求,架构,过程和管理等,反而代码构建这个与软件开发骨肉相连的环节反而被忽视了. 我们认为”代码是债务而不是资产”。最开始,团队会编写代码,做出产品,并用它来赚钱,但是,之后团队应该尽可能地寻找减少代码的方法和使代码尽量整洁,从而降低成本。软件界有一个真理,你拥有的代码越多,添加新内容所要付出的成本就越高。更坏的情况是,你所添加的所有内容都会堆在代码的顶端,接下来要添加内容的时候会成本会更高。如果你的代码结构越好,你做了越多的单元测试,你使用的数据库模式越好、越小、耦合越松,那么添加新代码所需要付出的成本就越少。因此OOP大师Craig Larman: “最好维护的代码就是没有代码,好的程序员的代码产量是负的,因为他通过减少代码来增加功能”。对比现实中,很多人以为,LOC(line of code)越多的feature越大,写LOC越多的程序员越牛。这其实是极其错误的观念. 因此我们必须有全面的管理制度让我们保持代码少而整洁。所以软件大师Michael Feathers认为"未来属于知道如何有策略地删除代码的公司”。持有代码的成本要比我们想象的大。意识到这一点的公司更具有竞争优势。 为了切实帮助软件企业降低企业项目开发成本,大面积提高软件工程师编程能力和代码质量管理能力,我们特别推出了实战训练营. 分享多家大型研发中心代码管理经验给大家。 该课程适应于各个阶段的开发群体.初级工程师能够透过大师的眼睛来看待编程,了解编程的价值观和原则;具有丰富经验的设计师和架构师可以通过模式进行反思,探究成功实践背后的意义.把价值观,原则和开发实践结合;管理者通过学习业界著名研发中心的管理经验和失败的教训,来制定自己公司的代码管理策略。 培训讲师:刘捷 -- 曾任BEA中国专业服务部高级技术顾问 2000年加入BEA中国区专业服务部,任高级技术顾问,主要负责BEA客户项目的架构设计和项目开发,技术支持。保证项目的成功实施,运行,维护。参加过全省、全国多个大型的计算机应用项目,设计的领域包括电信,银行、税务,社保等等。 技术能力: DB,UNIX,J2EE,SOA,WebLogic Server, WebLogic Integration, WebLogic Portal相关的架构设计。

相关主题
相关文档
最新文档