WordCount项目优化
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一项填
运行截图及扫描结果：
存在的主要问题如下：
（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。
