码迷,mamicode.com
首页 > 其他好文 > 详细

WordCount项目优化

时间:2018-04-07 20:05:49      阅读:213      评论:0      收藏:0      [点我收藏+]

标签:lsp   结果   软件质量   map   ldb   sig   hub   count   简单的   

1.基本任务

小组github地址:https://github.com/LongtermPartner/ExtendWordCount

PSP表格:

PSP2.1

PSP阶段

预估耗时

(分钟)

实际耗时

(分钟)

Planning

计划

60 60 

· Estimate

· 估计这个任务需要多少时间

60  60 

Development

开发

720 720 

· Analysis

· 需求分析 (包括学习新技术)

90   90

· Design Spec

· 生成设计文档

20 20 

· Design Review

· 设计复审 (和同事审核设计文档)

20  20 

· Coding Standard

· 代码规范 (为目前的开发制定合适的规范)

20  20 

· Design

· 具体设计

30  30 

· Coding

· 具体编码

300  240 

· Code Review

· 代码复审

60 60 

· Test

· 测试(自我测试,修改代码,提交修改)

180  240 

Reporting

报告

180  180 

· Test Report

· 测试报告

120 120 

· Size Measurement

· 计算工作量

30  30 

· Postmortem & Process Improvement Plan

· 事后总结, 并提出过程改进计划

30  30 
 

合计

 960 960 

接口的实现:

计数模块,由CountAndSort类中的parse函数实现,主要功能是对有效的输入文件进行读取并统计其单词词频。

由main函数调用,传入参数为输入模块分析得出的有效文件名,统计出各单词词频后,放入一个Map中(key为单词名,value为单词词频),返回值为此Map,供后面的排序模块使用。

测试用例的设计:

技术分享图片

 

此模块共使用了20个测试用例,由于模块功能较少,既采用白盒测试覆盖各判定,又有黑盒测试, 包括:

>>字母与数字的组合

>>字母与各种常用字符的组合

>>短横线在字母前

>>短横线在字母后

>>短横线在单词中间

>>字母大小写是否对单词有影响

等各种情况。

每个测试用例针对性较强,且单词数不多,都不可缺少,能较好地满足测试效率的要求。

单元测试及其评价:

技术分享图片

如图所示,对计数模块编写了测试脚本并进行了单元测试,20个测试用例通过。

此次测试根据需求列举了各种可能出现的情况,使这次测试可信度很高,且测试效率较高;

对被测模块,20个测试用例都通过了,在功能方面满足了用户提出的需求。

2.扩展任务

对开发规范的理解:

邹欣老师对代码规范和代码复审的讨论:http://www.cnblogs.com/xinz/archive/2011/11/20/2255971.html

(1)断行与空白的{ }行:

邹欣老师在博客中指出,为了程序精简、调试、结构清晰,尽量每个“{”或“}”都独占一行,即

if ( condition)
{
    DoSomething();
}
else
{
    DoSomethingElse();
}

  

我认为这一点很容易被忽视,比如我由于个人习惯,经常将左大括号写在前一行,虽然没影响,但看上去可能没那么清晰。

(2)命名:

对于一个好的命名,尽量使用匈牙利命名法,且让程序员一眼就能看出变量的含义甚至类型,避免在使用中出错。比如对一个简单的int变量,我们最好不要直接用i、j、k这种简单但完全看不出含义的变量名,而应该用能看出其含义的命名,易于自己、他人阅读代码,弄清含义,可读性高,且可维护性好。

(3)缩进:

在Eclipse中,换行时会自动进行缩进,但是在编写代码的过程中不断的增加、删除还是会出现缩进格式不太整齐的现象。

根据规范分析小组成员代码:

对17067负责模块的代码,就以上标准进行分析。

断行与空白的{ }行、命名规范:较为标准,如wordsCount、valueComparator等变量的命名,都较为规范、易于理解。

缩进:有些地方的缩进格式较为混乱,不容易一眼看清层次,如

private int getInt(String key) {
                
                int i=0;
                try{
                Pattern pattern=Pattern.compile("^\\d+");
                Matcher matcher=pattern.matcher(key);
                if(matcher.find()){
                    i=Integer.valueOf(matcher.group());
                }
                }catch(NumberFormatException e){
                    e.printStackTrace();
                }
                return i;
            }
            };

静态代码检查工具:

PMD,在Eclipse中的安装方法如下

选择Help菜单项,选择Install From Site...,并点击add键,在Name一项填“PMD for Eclipse Update Site”,Location一项填

 “https://dl.bintray.com/pmd/pmd-eclipse-plugin/updates/”,完成安装即可。

运行截图及扫描结果:

技术分享图片

存在的主要问题如下:

(1)AvoidCatchingGenericException:即抛出异常时最好指定异常的类型,而不是直接用Exception类型。

改进方法:因为要对某特定异常进行处理,改为catch(FileNotFoundException e)。

(2)Avoid printStackTrace(); use a logger call instead.:即在catch中最好不要直接用e.printStackTrace(),如果不对异常进行处理,可以直接throw抛出,若要处理则用自己的方法处理。

改进方法:由于已经要对此异常进行处理,删除e.printStackTrace()即可。

(3)无用的括号:某些表达式里没必要加括号的地方多加了括号。

改进方法:去掉某些无用的括号。

(4)IfElseStmtsMustUseBraces:即if或else语句必须用大括号括起。

改进方法:用大括号括起,更规范。

(5)LocalVariableCouldBeFinal:即某些局部变量可以被定义为final类型。

改进方法:将某些变量设定为final类型,更安全。

(6)OnlyOneReturn:即在try里有一个return,外面又有一个return。

改进方法:去掉try里的return语句,将return语句放在外面。

 

 小组代码主要问题:

代码没有太大问题,但不够规范,有些小问题,可以尽量改的规范一些。

3.高级任务

测试数据集:

技术分享图片

如图,测试数据集使用了一个1600多行的文本文件test.txt,其中包含了各类单词。

处理时长:

技术分享图片

如图,经过多次试验,处理此测试数据集的时间在300ms~400ms左右。

同行评审:

 每位小组成员都作为作者、讲解员、评审员、记录员等身份进行了评审。

经过评审,我们得出结论:影响程序性能的主要因素是计数和排序两个模块,即计数时对单词的判定方法和排序的算法快慢。

实际测试:

通过测试,我们发现制约程序性能指标的主要因素是计数和排序两方面,即和同行评审结果相似。

软件开发、软件测试、软件质量的关系:

在本次实践作业中,软件开发主要是第一阶段,即基本任务的完成,而二、三阶段要对软件进行修改,再提交,即二、三阶段也能反映开发过程;而软件测试则是贯穿整个始终,在一、二、三阶段都有体现,也反映了软件测试的重要性;软件质量则是在各阶段一点点变好。不论是单元测试、静态测试还是最后的压力测试,都影响着软件开发过程和软件质量。

 

>>小组贡献分:

经过小组讨论,小组贡献分为0.29。

WordCount项目优化

标签:lsp   结果   软件质量   map   ldb   sig   hub   count   简单的   

原文地址:https://www.cnblogs.com/meow/p/8688687.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!