wordcount优化

项目地址：https://github.com/YYCZ/WCPro

 

一.PSP表格

psp2.1	psp阶段	预估耗时（分钟）	实际耗时（分钟）
planning	计划	15	20
estimate	估计这个任务要多长时间	15	15
development	开发	300	360
analysis	需求分析（包括学习新技术）	30	60
design spec	生成设计文档	30	40
design review	设计复审（和同事审核设计文档）	20	30
coding standard	代码规范（为目前的开发制定合适的规范）	20	20
design	具体设计	40	60
coding	具体编码	300	360
coding review	代码复审	30	40
test	测试（自我测试，修改代码，提交修改）	60	60
reporting	报告	90	90
test report	测试报告	40	40
size measurement	计算工作量	10	10
postmortem&process improvement plan	事后总结，并提出过程改进计划	20	20
	合计	720	865

基础任务：

 

二.接口实现

在本次作业中，我负责的是其他功能及系统框架的编写，由于程序被封装为三个模块分别为输入，输出和核心功能，

我负责编写这三个模块的接口，通过主函数调用input类，core类和output类来实现程序的完整功能

首先将从shell获得的参数传递给Input模块。

如果参数符合要求的格式，Input模块将要统计的txt文件转为一个String对象传递给Core模块。

Core模块对文本处理得到排序过的词频列表，然后将该列表传给Output模块输出。

 

三.测试

 我负责的测试部分与其说是单元测试，更像是集成测试。

部分测试用例如图：

 

部分单元测试的结果如下：

 

在考虑测试时我主要考虑了

1）框架逻辑的正确性。

2）各个模块是否能正确衔接得到最终结果。

于是我首先设计了一些无效输入的测试用例，在这些输入下，程序应当直接输出错误信息。

然后我设计了一些文本作为测试用例，它们的目的在于

·测试输入模块能否准确无误地获得文本字符串并将其传给核心模块处理。

·测试核心模块能否正确完成其功能并将处理结果传递给输出模块

·测试输出模块的正确性

四.小组贡献分

根据小组讨论的结果，我的小组贡献率为0.23（此为基本，扩展及高级任务的总体贡献率）

 

扩展任务：

 

五.规范理解

我阅读的是《阿里巴巴开发手册》中的规范，由于之前编写代码时换行较为随意，下面这条规范给了我很大的启迪。

尤其是缩进的空格数，逗号周围的换行等规范，在实践后，发现该规范在一定程度上增加了代码的可读性，有利于和组员沟通

规范：

 【强制】单行字符数限制不超过 120 个，超出需要换行，换行时遵循如下原则： 

1） 第二行相对第一行缩进 4 个空格，从第三行开始，不再继续缩进，参考示例。 

2） 运算符与下文一起换行。 

3） 方法调用的点符号与下文一起换行。 

4） 方法调用时，多个参数，需要换行时，在逗号后进行。 

5） 在括号前不要换行，见反例。

正例：
StringBuffer sb = new StringBuffer(); 

// 超过 120 个字符的情况下，换行缩进 4 个空格，点号和方法名称一起换行 

sb.append("zi").append("xin")...

    .append("huang")...

    .append("huang")...

    .append("huang"); 
反例：

StringBuffer sb = new StringBuffer(); 

// 超过 120 个字符的情况下，不要在括号前换行 

sb.append("zi").append("xin")...append

      ("huang");  
 
// 参数很多的方法调用可能超过 120 个字符，不要在逗号前换行

  method(args1, args2, args3, ... 

     , argsX);

六.代码评价

本次代码评价我选择了17176陈鹏旭同学的部分代码进行评价，总的来说，我认为其代码风格符合简明，易读，无二义性的原则。

其代码分行明显，通过不同的缩进来清楚的分割开不同部分使其他人更方便的理解其代码。对于不同的语句分成不同的行，避免了阅读长行代码的疲累感。

同时，注释精简而不繁琐，让人很清楚的领会到其代码的含义。当然，存在一点点小瑕疵是用if语句时，大括号的使用没有分行，和小括号堆叠在一起较为琐碎

 

 

七.静态扫描

经过一定的考虑，本次静态代码检查我们选择了使用check style工具来做静态代码检查，

此为下载地址：http://checkstyle.sourceforge.net/

对于我自己的代码扫描结果如下：

各问题及其对应位置均如图所示，综合来看，存在以下问题：

1.缩进没有符合规范，要么是缩进符数量不对，要么是使用了tab制表符

2.if语句大括号未符合规范

3.”=“前后未加空格 

从整个小组的代码来看，均存在缩进符的问题，应从一开始就制定统一的规范要求方面改进

高级任务：

 

八.测试数据集

出于对测试数据集应该使用一个总够大体量的且有着丰富的句法结构，词汇量丰富的文本来进行测试的考虑，我们选择了英文小说《飘》进行测试，

使得统计结果丰富多元，同时一定程度上考验了程序的性能，为其造成一定的压力，便于优化前和优化后的对照

九.程序性能指标

我们一开始选择直接对文本进行统计词频，效率可想而知不算很高但胜在实现方法简单，下为优化前结果

 

十.评审过程

参加人员：17172张海涛（主持，记录），17176陈鹏旭（评审），17178余浩宇(评审)，17156余笑童（评审）

17172指出程序中最耗时的部分是核心处理模块，直接进行统计的方法略为粗暴，影响效率

17178分享了编写核心处理模块时的思路，提出可以通过改进算法比如计数排序来实现效率的提高。

17172和17156表示赞成。

17176提出哈希表也可以用来解决。

17156探讨了用计数排序和哈希表进一步提升排序速度的可行性。

评审结果决定采用哈希表来进行优化

十一.优化

使用哈希表后，结果如下：

　　

在使用哈希表后，程序的执行速度提升了将近二十倍。分析可知时因为词频统计算法的复杂度从O(n^2)降到了O(n)。

十二.总结

  本次项目实践使我感受到以下几点：

1.软件开发和软件测试需要并发执行，在获得需求后就可以开始着手测试的设计，同时模块完成后需进行单元测试，确保模块正常运行。

2.无论时代码编写过程中还是测试后都应注意代码是否符合规范。

3.和队友讨论统一接口和规范的重要性，便于代码的整合和优化方案的提出，便于提高软件质量