截止日期
2018年3月29日23:59
要求
1. 对源文件（*.txt,*.cpp,*.h,*.cs,*.html,*.js,*.java,*.py,*.php等，文件夹内的所有文件）统计字符数、单词数、行数、词频，统计结果以指定格式输出到默认文件中，以及其他扩展功能，并能够快速地处理多个文件。
2. 使用性能测试工具进行分析，找到性能的瓶颈并改进
3. 对代码进行质量分析，消除所有警告
http://msdn.microsoft.com/en-us/library/dd264897.aspx
4. 设计10个测试样例用于测试，确保程序正常运行（例如：空文件，只包含一个词的文件，只有一行的文件，典型文件等等）
5. 使用Github进行代码管理
6. 撰写博客
基本功能
1. 统计文件的字符数（只需要统计Ascii码，汉字不用考虑）
2. 统计文件的单词总数
3. 统计文件的总行数（任何字符构成的行，都需要统计）
4. 统计文件中各单词的出现次数，输出频率最高的10个。
5. 对给定文件夹及其递归子文件夹下的所有文件进行统计
6. 统计两个单词（词组）在一起的频率，输出频率最高的前10个。
7. 在Linux系统下，进行性能分析，过程写到blog中（附加题）
注意：
a) 空格，水平制表符，换行符，均算字符
b) 单词的定义：至少以4个英文字母开头，跟上字母数字符号，单词以分隔符分割，不区分大小写。
英文字母：A-Z，a-z
字母数字符号：A-Z，a-z，0-9
分割符：空格，非字母数字符号
例如：”file123”是一个单词，”123file”不是一个单词。file，File和FILE是同一个单词。
如果两个单词只有最后的数字结尾不同，则认为是同一个单词，例如，windows，windows95和windows7是同一个单词，iPhone4和IPhone5是同一个单词，但是，windows和windows32a是不同的单词，因为他们不是仅有数字结尾不同
输出按字典顺序，例如，windows95，windows98和windows2000同时出现时，输出windows2000
词组的定义：windows95 good， windows2000 good123，可以算是同一种词组。按照词典顺序输出。三词相同的情形，比如good123 good456 good789，根据定义，则是 good123 good123 这个词组出现了两次。
c) 输入文件名以命令行参数传入。需要遍历整个文件夹时，则要输入文件夹的路径。
d) 输出文件result.txt
characters: number
words: number
lines: number
<word>: number
<word>为文件中真实出现的单词大小写格式，例如，如果文件中只出现了File和file，程序不应当输出FILE，且<word>按字典顺序（基于ASCII）排列，上例中程序应该输出File: 2
e) 根据命令行参数判断是否为目录
f) 将所有文件中的词汇，进行统计，最终只输出一个整体的词频统计结果。
项目管理
1. 分析整理需求，完成PSP表格
PSP是卡耐基梅隆大学（CMU）的专家们针对软件工程师所提出的一套模型：Personal Software Process (PSP， 个人开发流程，或称个体软件过程)。
一个功能完备的程序不是一蹴而就的。通过将词频统计的需求划分为4个部分，可将一个大任务划分为可操作的小任务，同时最好按照任务难度或紧急程度指定各个任务的完成次序。因此，在动手开发之前，要先估计将在程序各模块开发所需耗费的时间，以及完成整个项目所需的时间，将这个[估计值]记录下来，写成PSP 的形式。
PSP的目的是：记录工程师如何实现需求的效率，和我们使用项目管理工具（例如微软的Project Professional，或者禅道等）进行项目进度规划类似。
有关PSP的更多内容，请自行阅读邹欣老师的博客：
http://www.cnblogs.com/xinz/archive/2011/10/22/2220872.html
PSP可用teambition工具制作
2. 使用Github进行代码管理
使用PSP做好规划之后，第二步当然是进行编码实现，此时，除了选择合适的编程语言，还需要学会良好的源代码管理。
请阅读邹欣老师的博客：源代码管理，了解源代码管理的10个实践问题。
本次作业要求使用Github进行源代码管理，代码有进展即签入Github。签入记录不合理的项目会被助教抽查询问项目细节。
对代码签入的具体要求如下：根据需求划分功能后，每做完一个功能，编译成功后，应至少commit一次。本例中，至少应区分基本功能和扩展功能，即分别针对基本功能、扩展功能，编译成功后，总共至少应commit两次。具体的功能划分，请自行定义，并在撰写博客时体现出来，遵循自己对需求的功能划分来提交代码即可。
对Commit不是很熟悉的话，请阅读阮一峰的博客：Commit message 和 Change log 编写指南，了解更多细节。
3. 设计测试用例，编写单元测试
作为一门测试的课程，测试才是重点。请根据自己以往积累的测试经验，结合本周介绍的测试用例设计方法，在编码完成之后，提交产品之前，设计测试用例，并编写单元测试，对自己的项目进行测试。
首先，至少应采用白盒测试用例设计方法来设计测试用例，其他测试方法不限。其次，要设计至少10个测试用例，确保你的程序能够正确处理各种情况。最后，结合测试评估的要求，对自己的测试设计进行评价，这些测试用例能满足该程序测试的要求吗？
另一个重要的措施是要把单元测试自动化，这样每个人都能很容易地运行它，并且可以使单元测试每天都运行。每个人都可以随时在自己的机器上运行。团队一般是在每日构建中运行单元测试的，这样每个单元测试的错误就能及时被发现并得到修改。
推荐阅读邹欣老师关于单元测试和回归测试的博客：
http://www.cnblogs.com/xinz/archive/2011/11/20/2255830.html
博客要求
1. 需求分析，估计各部分所需时间，给出PSP表格
2. 记录实际完成各部分时间
3. 对代码质量和性能进行分析
4. 测试用例设计和分析过程
5. 描述你在次项目中获得的经验
评分标准
1. 统计文件的字符数(2分)
2. 统计文件的单词总数(2分)
3. 统计文件的总行数(2分)
4. 统计文件中各单词的出现次数(2分)
5. 对给定文件夹及其递归子文件夹下的所有文件进行统计(4分)
6. 统计两个单词（词组）在一起的频率，输出频率最高的前10个(4分)
以上六个结果输出错误则对应子任务得-2分，全部输出正确则按运行时间确定排名(用时按升序前30%得满分16分，30%-70%得15分，后30%得14分)。
7. 博客撰写(代码实现过程，性能分析、优化报告等)(4分)
8. 在Linux系统下，进行性能分析，过程写到blog中（附加题，2分）
代码提交地址：
https://github.com/eudaem/homework1
注意：作业延迟，1周内补交，0分；不交作业-10分。