1. 预计时间
● 对问题总体的理解、规划:10 min
● 设计编写程序:5 h
● 调试: 分模块-40 min; 总体-40min
● 测试(性能分析)、改进:1 h
2. 实际用时
● 对问题总体的理解、规划:10 min
总的理解了一下题意,打算用C#写。程序数据结构不复杂,没有打算用OOP。
● 设计编写程序:
i) 模式判断:读参数,确定是哪种模式(普通、e2、e3)。
这部分比较简单。10min左右完成。
ii) 读出所有子文件:采用递归的方法。
这部分查了一下C#文件方面的类和接口的用法。40min左右完成。
iii) 分词:把文件的单词划分出来。
这部分比较坎坷。在做simple mode的时候,学习了一下正则表达式的书写,完成大约用了1h 10min。先做了Simple mode的统计词频,然后再做extend mode的时候,原本是以为只需要选择不同的正则表达式即可,然而C#的正则的Matches方法是非重叠匹配,在做2词、3词连续时匹配就不适用了。后来重写了2词、3词连续时分词的方法,但是逻辑有点繁琐复杂,限于时间凑合用了。算上查正则的时间,可能用了2.5h吧。
ix) 词频统计:统计某个词(词组)出现的频率。
这部分用的方法也有点蠢,因为在统计时不敏感大小写,但是输出时要考虑原有的ACII值排序,所以比较麻烦,用的方式是先对分词的结果(一个ArrayList)进行自带的Sort排序。这样得到的结果是字典序,大写在后。然后再遍历ArrayList,记录前一个单词,对比当前的单词。因为相同的单词都是相邻的,所以可以进行比较、处理。最后得到一个Dictionary记录单词与出现频率。
x) 排序输出:(统计出现频率最高的词组)按ASCII值排序并输出到文件。
这部分也是意想不到的挑战。之前以为按值排序应该蛮简单的,但是加上ASCII值的要求又麻烦了一些。还去学写了IComparer,不过后来发现用StringComparer.Ordinal就可以了。虽然花了意外的时间,但是也有很大的收获。
● 调试:
我的习惯是写完一个模块就会做一些基本的测试。所以调试的时间比较零碎了。估计总计在2h左右。
● 测试(性能分析)、改进:
这里最大的坑是我的性能分析工具。因为电脑上空间不太足,又已经有安装VS2010,去查了一下2010也有性能分析的功能,就打算就用2010了。谁知最后一天做分析时,自己的2010不知道为何一分析就崩溃。下载2013后结果空间不足不能安装,又用分区工具捣鼓了下。但是安装时间太长,眼看着就要到deadline……于是接了同学的电脑,他的VS2010能用分析,让我妥妥地泪奔了。但是时间实在太短,没来及做很多改进了,主要是分析。这个装工具的时间就不知道该怎么算了……工作了估计不到2h。
3. 性能分析
这是我作死的大坑……
来看“大数据”的处理吧:包含2.27G的文件夹,主要是找的一些程序安装的文件夹什么的。
CPU的使用率不理想啊……然后导出到excel函数独占率:
看来WordFren,也就是词频统计占了大头,ReadWord,也就是分词也不少。后面分析两词、三词的结果也是类似,就先不放上来了。
不过呢我也没想到优化这里的比较好的方面(主要没时间了)。
后面有机会再补充吧。
4. 测试用例
1)空文件夹
输出为空,没问题。
2)嵌套文件夹
这也是最基本的了,没问题。
3)【单】词模式
测试了输出格式,“3个英文字符打头”等要求,出现频率,及按ASCII排序输出。
4)【双】词模式
类似,并测试了“仅一个空格间隔”的要求。
5)【三】词模式
类似。
6) 迷惑的单词模式
输入含File、file的文件,测试输出时能够按ASCII值选择名字。
7) 迷惑的双词、三词模式
输入类似file File File file FILE的文字,测试是否正确统计重复输出。
8) 丰富的后缀
测试了除txt外的格式文件。
9) 压力测试-1
测试了大约1M的文件。
10)压力测试-2
测试了大约2.27G的文件。(性能分析中的分析组)
5. 感想
现在也在忐忑,到底程序还有没有bug。0 point 还是有点吓人的。一个很大的教训是过于放心自己,开始的太晚了。以致最后工具出现问题,导致对性能的改进没有时间了。
从这个项目也收获了很多,一是更熟悉了C#,二是学习了正则表达式,三是学到了性能分析这个功能。
当然!最后的程序自己还是很不满意的,因为不算漂亮,这也是限于时间的原因,查C#类和接口的资料也占了很多时间。
总之,希望下一次自己能做得更好。