github地址
PSP表格
PSP2.1 |
PSP阶段 |
预估耗时(分钟) |
实际耗时(分钟) |
Planning |
计划 |
10 |
20 |
· Estimate |
· 估计这个任务需要多少时间 |
10 |
15 |
Development |
开发 |
500 |
480 |
· Analysis |
· 需求分析 (包括学习新技术) |
80 |
100 |
· Design Spec |
· 生成设计文档 |
30 |
30 |
· Design Review |
· 设计复审 (和同事审核设计文档) |
30 |
40 |
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
5 |
10 |
· Design |
· 具体设计 |
60 |
55 |
· Coding |
· 具体编码 |
450 |
460 |
· Code Review |
· 代码复审 |
60 |
120 |
· Test |
· 测试(自我测试,修改代码,提交修改) |
150 |
200 |
Reporting |
报告 |
100 |
120 |
· Test Report |
· 测试报告 |
50 |
50 |
· Size Measurement |
· 计算工作量 |
10 |
20 |
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
20 |
30 |
|
合计 |
1565 |
1750 |
接口设计
经由团队讨论,本次实验分为四个模块,分别为输入检测,单词检测及统计,单词排序,文本输出。我负责的模块为单词检测及统计。该接口返回一个map实体,接受一个文件路径参数。核心思路,提取文件中所有满足单词格式的字符串,并保存到一个String数组中,遍历该数组统计词频并保存结果到一个map实体中,返回该map实体。
代码如下:
public static Map<String, Integer> scan(String path)throws IOException { //读取文档并将所有单词放入list并统计 InputStreamReader isr = new InputStreamReader(new FileInputStream(path)); BufferedReader br = new BufferedReader(isr); String str=null; List<String> lists = new ArrayList<String>(); //存储过滤后单词的列表 while((str=br.readLine())!=null){ String[] tmp = str.split("[^a-zA-Z-]"); //过滤出只含有字母的 for(int i=0;i<tmp.length;i++){ if(tmp[i].length()!=0) { //最后带短横线的但未链接的单词去掉短线 if((tmp[i].substring(tmp[i].length()-1, tmp[i].length())).equals("-")) { if(tmp[i].length()!=1)//避免单个横线时输出空字符 { lists.add(tmp[i].substring(0, tmp[i].length()-1)); } } else { lists.add(tmp[i]); } } } } isr.close(); Map<String, Integer> wordsCount = new TreeMap<String,Integer>(); //存储单词计数信息,key值为单词,value为单词数 //单词的词频统计 for (String li : lists) { if(wordsCount.get(li) != null){ wordsCount.put(li,wordsCount.get(li) + 1); }else{ wordsCount.put(li,1); } } return wordsCount; }
测试设计过程
根据测试文件,得到一个保存有正确的单词及词频的map实体,再将此实体与Main.scan()返回的map实体比较。
单元测试截图
单元测试分别进行了白盒测试、黑盒测试和压力测试:
1-10:白盒测试,根据路径覆盖设计的测试用例;
11-20:黑盒测试,利用随机选取的单词组,以及手动随机输入字符的形式来获取测试用例;
21-22:压力测试,测试用例中包含大量单词,以千记位,此时代码的执行效率收到明显影响。对比测试21和22,尤其是当文件中包含有大量不常用字符时,代码效率下降跟为明显。
开发规范说明
选择的是Google Java编程风格指南
中文版链接:https://blog.csdn.net/zen99t/article/details/50763231
代码分析
评审的是SortMap(输出排序)模块的代码,该代码基本符合编程规范。其中有所不符合的是:
1. import不要使用通配符;
2. 大括号的使用,即使只有一条语句(或是空),也应该把大括号写上;
3. 块缩进,两个空格。部分缩进未达到要求。
命名规范方面,该模块与规范一致,类名都以UpperCamelCase风格编写,方法名都以lowerCamelCase风格编写,参数名以lowerCamelCase风格编写,未出现单词缩写等。
静态代码检查工具
采用了多种工具,并比对发现各种工具的检测规则不尽相同。
有PMD,findbugs,checkstyle,所需插件均能在该站点找到:http://sourceforge.net/
工具扫描结果
PMD和findbugs扫描结果都为无错误,选用其他代码进行展示错误结果。
Checkstyle规范较为严格,对缩进空格有着严格的规定,导致所有代码都不符合规范,而findbugs和PMD则发现不了问题。这说明本次实验代码还是较为符合编程规范的。其遵循的好的规范主要都在Google Java编程风格指南中可以找到。
小组代码分析
本次小组实验的代码基本还是比较符合规范的,本次小组实验的代码基本还是比较符合规范的,但是整合过程出现了些小纰漏,与前期商讨不足不无关系。其次,就是模块划分的不够严谨,注释方面不够详尽,部分模块的代码可读性不够高。