1、GitHub地址：https://github.com/huanf921/WC
2、PSP表格
|
PSP2.1 |
Personal Software Process Stages |
预估耗时（分钟） |
实际耗时（分钟） |
|
Planning |
计划 |
30 |
35 |
|
· Estimate |
· 估计这个任务需要多少时间 |
30 |
35 |
|
Development |
开发 |
1530 | 1475 |
|
· Analysis |
· 需求分析 |
120 |
100 |
|
· Design Spec |
· 生成设计文档 |
30 |
30 |
|
· Design Review |
· 设计复审 |
40 |
60 |
|
· Coding Standard |
· 代码规范 |
20 |
40 |
|
· Design |
· 具体设计 |
60 |
80 |
|
· Coding |
· 具体编码 |
1200 | 1000 |
|
· Code Review |
· 代码复审 |
30 |
40 |
|
· Test |
· 测试（自我测试，修改代码，提交修改） |
30 | 35 |
|
Reporting |
报告 |
80 | 90 |
|
· Test Report |
· 测试报告 |
30 | 50 |
|
· Size Measurement |
· 计算工作量 |
20 | 20 |
|
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
30 | 20 |
|
合计 |
1640 | 1600 |
3、解题思路
在做这次项目的时候，我首先在理解分析项目需求的时候，就花了比较多的时间，因为如果在需求方面理解错误的话，后续进行开发时会引起很多不利的影响。
题目描述中已经指出这是一个模仿已有wc.exe功能的命令行程序，并且所有参数都从命令行获取。所以我的思路是直接将题目所要求的功能分别进行封装，而后通过一个主类WordCount将这几种功能糅合起来。也即是说，通过主类将获取命令行参数与各个功能类所提供的功能联系起来，在主类中对用户输入的命令进行相应的处理，所得到的功能参数和文件路径再根据该参数对应的功能类分别调用相应的方法去实现每条命令的要求。
基本功能类BasicFnc中封装了“-c”、“-w”、“-l”这几个功能的实现方法，扩展功能类ExtendFnc中封装了“-s”、“-a”的实现方法，而高级功能类SeniorFnc中封装的则是图形交互界面。在这次的设计中，我原本是按照这个计划去实现每一个小功能，不过实际执行起来才发现，有些功能之间需要相互关联才能实现题目所要求的效果。就像是递归功能，我原本的思路是直接在ExtendFnc中直接在传入“-s”参数时实现递归统计，但再重新仔细地阅读题目需求后才发现应该在主类中设计“-s”与其他功能符的组合，而在ExtendFnc中对“-s”的设计则是只做递归保存文件的处理。
再有则是以下我在考虑几个具体功能的实现时的思路：
基本的字符数，行数，词数的统计较为简单，而递归统计的功能我则是考虑通过List来保存当前文件目录下的所有文件，之后再根据第二功能参数的情况来选择具体统计哪一项源程序特征。
通配符方面，我是将它与递归一并处理，在判断第二功能参数之前先判断当前路径是否包含通配符，如若包含则直接用正则表达式匹配事先在List中存好的递归文件列表，筛选出符合条件的文件（相当于文件过滤作用）进行进一步的特征统计。
特殊行数的统计则是分别对题目要求的情况和正常的情况综合考虑，才能去写相应的正则表达式匹配和判断。至于最后一个图形界面的编写，在以上功能都近乎完善之后，基本上算是最简单的一环，对选中的相应文件进行信息统计时，只要添加合适的界面构件及其监听器即可，而监听方法可直接联系其他功能类中的方法直接调用。
4、设计实现过程
整个设计构成其实较为简单，以基本功能、扩展功能、高级功能来封装类，而我在实现的时候，通过在WordCount主类中定义的几部分类变量（文件特征的整数变量，图形界面的checkBox是否被选取的布尔变量以及递归统计时保存所有递归所得文件的List<File>类对象），使主类与这几个功能类之间得以相互联系，算是起到桥梁作用。后期实现图形界面功能时，也是通过这道桥梁向基本功能类和扩展功能类获取所需的统计信息，才能在文本域显示。而Help类主要是用来向用户提供程序的使用说明，直接在主类中调用即可。
5、测试运行
本次项目设计过程中，进行了多次手动的单元测试，以确保每一个小功能在初步设计后的错误率尽可能降低，同时也降低后期代码复审的工作量，提高了整体的开发效率。
这是在基本功能中的单元测试，测试结果：
这是在扩展功能中的单元测试，测试结果：
以上单元测试都符合预期结果。
在完成整个程序后，则是建立一系列测试文件：
空文件 ：D:\WC_Test\2\21\212
只有一个字符的文件：D:\WC_Test\1\11\e.c
只有一个词的文件：D:\WC_Test\1\11\f.java
只有一行的文件:D:\WC_Test\1\11\g.txt
一个典型的源文件:?D:\WC_Test\1\12\121\a.java
测试结果均与预期结果一致。
测试递归与通配符功能
递归统计了该目录下的所有文件对应特征的信息，符合预期结果
递归统计了符合通配条件的文件特征信息，符合预期结果
测试图形界面功能
在首界面选择想要统计的文件特征项后，选择特定文件进行统计并在文本域内返回各项特征信息，符合预期结果。
6、项目总结
代码覆盖率：
本次项目整体来说实现过程还算比较顺利，尽管中间有些过程稍微困难了一点，但是却让我很深刻地体会到了“做项目”的感觉，不仅仅是说自己尽可能独立做一个项目，更为关键是让我清晰地经历了一个完整的项目开发流程。跟课设不同，这次个人项目实践要求更加全面，项目的具体编码设计只是占据了其中一个主要方面而已，还有单元测试、回归测试以及代码覆盖率等多项工作和指标需要自己去完成，这确实让我感受到很多。个人觉得这次项目还有很多不足，整体代码显得有些冗余，在封装方面也做的不够好，希望自身能在后续的项目实践中发现更多问题并逐步解决。
原文地址：https://www.cnblogs.com/futurelv99/p/11588651.html