剛開始心得都寫到了每個小組成員的個人博客上了。現在我將心得進行一下綜合，在團隊博客上發表。
對於，這次的詞頻統計作業，有一部分小組成員感覺到有一定困難。
具體的困難體現在以下幾點：
1、對要使用語言不了解，c++和c#都不會的組員有一部分，不會這兩門語言的組員往往比較缺乏面向對象語言的學習能力。
如果加上沒有java的掌握，那么做這次作業的難度就有點大了。這樣的組員有幾個，他們完成這次的作業就會覺得吃力，一門新語言，新的編譯環境。
加上沒有類似的經驗，這對他們是不小的挑戰。
2、不知道c#對文件的操作，在對文件進行查找的時候遇到了困難，有一部分人在做之前沒有考慮算法效率的問題，只想着完成目標，在編完程序后開始測試時
才發現之前的算法完全不能應對大數據量的問題，他們用了遞歸查找文件，文件層次太深時會出現錯誤。還有人遞歸的同時對文件進行詞頻統計，那樣加劇
了程序的負擔。最后效率不僅相差很大，還容易不出結果。
3、在數據結構的選擇和程序的實現上沒有細加考慮。這里具體的體現是，有些人在對單詞是否已經存在的查找上用了逐個查找的方法那么就是O（n）的一個算法。
而一部分人用的是hashmap那是一個O（1）的方法，這樣子一開始跑大的測試數據時效率就體現出來了。同時排序方面，也一樣，有人寫快排，有人冒泡，
有人選擇。在程序效率方面是我們平時寫作業時很少考慮的東西，這次成了矛盾的集中體現。
4、還有一個不普遍的問題，那就是一些人是先將單詞都記錄下來，然后再做處理，而且他存儲了許多多余的信息，那么他的程序一跑起來占用的內存竟然大到1G左 右，相當的可怕。
5、程序的可擴展性和程序效率的取舍上，有人使用的是正則表達式來匹配字符串，那么有一個很大的好處就是當需求改變時，程序需要做的僅僅是需該一下正則表達 式，這樣可以高效、准確的再次提供新版本的程序。但是正則匹配是一個很強大的東西，他會存儲一些不很多的信息，可能根本使用不到。這樣就在效率上和用自 動機寫出的程序上產生了差距。自動機的缺點是容易錯，一旦修改回很麻煩。（這一條不太有人考慮，是大多數人都欠缺的）
在了解困難過后，小組成員們又給出了改進的方法，首先是在對面向對象知識缺乏的同學，他們表示會加強語言和面向對象知識的學習。對語言的掌握不求多，但求精；因為這些高級語言幾乎都是相似的。再有就是在寫程序的之前要充分的考慮，這樣會比看到自己的程序根本不能完成既定目標然后重寫要好很多。要考慮程序的時間和空間復雜度。還要考慮程序的可擴展、維護性。這些都是以前我們很少遇到過的，是一段學習的經歷。