词频统计（心得）

　　刚开始心得都写到了每个小组成员的个人博客上了。现在我将心得进行一下综合，在团队博客上发表。

　　对于，这次的词频统计作业，有一部分小组成员感觉到有一定困难。

具体的困难体现在以下几点：

　　　　1、对要使用语言不了解，c++和c#都不会的组员有一部分，不会这两门语言的组员往往比较缺乏面向对象语言的学习能力。

　　　　　　如果加上没有java的掌握，那么做这次作业的难度就有点大了。这样的组员有几个，他们完成这次的作业就会觉得吃力，一门新语言，新的编译环境。

　　　　　　加上没有类似的经验，这对他们是不小的挑战。

　　　　2、不知道c#对文件的操作，在对文件进行查找的时候遇到了困难，有一部分人在做之前没有考虑算法效率的问题，只想着完成目标，在编完程序后开始测试时

　　　　　　才发现之前的算法完全不能应对大数据量的问题，他们用了递归查找文件，文件层次太深时会出现错误。还有人递归的同时对文件进行词频统计，那样加剧

　　　　　　了程序的负担。最后效率不仅相差很大，还容易不出结果。

　　　　3、在数据结构的选择和程序的实现上没有细加考虑。这里具体的体现是，有些人在对单词是否已经存在的查找上用了逐个查找的方法那么就是O（n）的一个算法。

　　　　　　而一部分人用的是hashmap那是一个O（1）的方法，这样子一开始跑大的测试数据时效率就体现出来了。同时排序方面，也一样，有人写快排，有人冒泡，

　　　　　　有人选择。在程序效率方面是我们平时写作业时很少考虑的东西，这次成了矛盾的集中体现。

　　　　4、还有一个不普遍的问题，那就是一些人是先将单词都记录下来，然后再做处理，而且他存储了许多多余的信息，那么他的程序一跑起来占用的内存竟然大到1G左　　　　　　右，相当的可怕。

　　　　5、程序的可扩展性和程序效率的取舍上，有人使用的是正则表达式来匹配字符串，那么有一个很大的好处就是当需求改变时，程序需要做的仅仅是需该一下正则表达　　　　　　式，这样可以高效、准确的再次提供新版本的程序。但是正则匹配是一个很强大的东西，他会存储一些不很多的信息，可能根本使用不到。这样就在效率上和用自　　　　　　动机写出的程序上产生了差距。自动机的缺点是容易错，一旦修改回很麻烦。（这一条不太有人考虑，是大多数人都欠缺的）

在了解困难过后，小组成员们又给出了改进的方法，首先是在对面向对象知识缺乏的同学，他们表示会加强语言和面向对象知识的学习。对语言的掌握不求多，但求精；因为这些高级语言几乎都是相似的。再有就是在写程序的之前要充分的考虑，这样会比看到自己的程序根本不能完成既定目标然后重写要好很多。要考虑程序的时间和空间复杂度。还要考虑程序的可扩展、维护性。这些都是以前我们很少遇到过的，是一段学习的经历。