WordCount项目优化

Posted 2020-10-30 灯火如常

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。