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#类和接口的资料也占了很多时间。
总之，希望下一次自己能做得更好。