Github:

(注：Github上的所有代码由我代为提交)

PSP:（注：部分实际用时不准确)

PSP2.1	PSP阶段	预估耗时 （分钟）	实际耗时 （分钟）
Planning	计划
· Estimate	· 估计这个任务需要多少时间	10	10
Development	开发
· Analysis	· 需求分析 (包括学习新技术)	45	30
· Design Spec	· 生成设计文档	40	40
· Design Review	· 设计复审 (和同事审核设计文档)	40	40
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	10	5
· Design	· 具体设计	30	50
· Coding	· 具体编码	600	625
· Code Review	· 代码复审	60	60
· Test	· 测试（自我测试，修改代码，提交修改）	1200	1120
Reporting	报告
· Test Report	· 测试报告	30	30
· Size Measurement	· 计算工作量	10	10
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	10	10
	合计

 

分析：

其实可以用MapReduce做分布式版本

首先分出单词，存在Trie树里，然后dfs排下字典序，然后双关键字排序取前100。可以只排出前100的序，但是对性能影响不大。

 

实现：

本次作业我实现了词频统计和排序部分

实现的接口如下：

TrieNode:Trie树的节点，本身代表着一个字符，从根到Node的路径表示了某个单词的某个前缀。如果该Node代表某个单词，getCount函数返回它的词频，Trie类保证包外的代码只可能获取到代表单词的节点。

public class TrieNode {    public int getCount() {    }}

Trie树：

curWordAppendChar函数为Trie树的正在输入的单词在末尾附加一个字符

curWordEnd函数终结当前正在输入的单词，接下来的Append操作将从头开始

sortWords函数将所有输入的单词排序并返回TrieNode列表

getWord函数返回输入的TrieNode所代表的单词

public class Trie {    public Trie() {    }    public void curWordAppendChar(char ch) {    }    public void curWordEnd() {    }    public TrieNode[] sortWords() {    }    public String getWord(TrieNode tail) {    }}

大致实现为：建立Trie树，接收，存储并统计输入的单词。在排序过程中首先dfs遍历Trie树，生成字典序，之后使用词频和字典序做双关键字排序。

时间复杂度为O(n)+O(m log m)，其中m为不同的单词数，m<n且在通常情况下有m<<n，m<=5000

排序部分可以采用插入排序只取前100个的方式改进时间复杂度为O(m)或者使用快速排序/堆排序只取前100的方式优化，但由于m不大，不会有很大的改进。

 

测试设计过程：本次我的单元测试包含了5个手工编写的测试用例和15个随机生成的较大的测试用例。

测试方法如下：输入内容为以空格或换行符隔开的单词，输出全部单词的词频统计结果

Testcase1:普通的统计

Testcase2:单词词频相同，测试对字典序的处理

Testcase3:存在字典序靠前的单词词频较低，验证程序是否正确处理了字典序和词频的关系

Testcase4:单词有公共的前缀，测试Trie树的正确性

Testcase5:单词有大小写，测试程序对大小写字母的处理

Testcase6~20:随机生成的测试数据

测试用例设计清单：

 

测试运行结果：

 

程序通过了全部单元测试

 

静态测试：

静态测试采用了IntelliJ IDE的静态测试插件和阿里编码规范的插件，下载地址不详。

由于编码过程中IDE实时地给出了醒目的提示，在编码过程中静态测试的错误被立即修改了，因此最终没有统计结果，但是代码一经编写即通过了静态测试，基本符合编码规范。

 

性能测试：

我们进行了代码的性能测试，使用了几本较大的电子书和随机生成的大型数据(最大数据大小约为数百MB)。具体结果参见组员

性能测试使用的随机生成的大数据点未使用Git维护，但是在仓库中存有生成用的代码。

测试使用的最大数据点达136MB，耗时约3秒。

程序基本为线性复杂度，主要制约程序效率的因素为数据的读入，在算法上很难进行改进。

可进行的改进为：

1、使用C语言等效率较高的编译型语言重写该项目，但是会丧失跨平台等方面的优势

2、分段读入文件以减少内存占用，但会增加程序运行的时间。

3、进行并行化编程，采用多线程/多机器计算。这是目前最广泛使用的优化手段，但由于时间关系未予实现

 

编码规范：

《阿里巴巴Java开发手册》：

[强制]大括号使用规范：

空代码段写成{}

左大括号前不换行，左大括号后换行

右大括号前换行，右大括号后如果跟else等代码则不换行，否则换行

例如：

void enptyFunction(parameter){}if(condition){    code；}else if(condition){    code；}else{    code;}

简洁清晰，容易判断代码段的范围和代码所属的代码段

本组成员均遵循了这一要求

 

注：

所有随机数据和输出结果采用Unix的换行格式，在Windows记事本下可能显示不正确。请用写字版或其他编辑器打开。

使用的exe4j为未注册版本，程序运行时有弹窗