标签：路径 evel 效率 自我 table 封装 需求 nal hub
1.GitHub项目
https://github.com/Littlehui3/wc
2.用时表格
|
PSP2.1 |
任务内容 |
计划完成需要的时间(min) |
实际完成需要的时间(min) |
|
Planning |
计划 |
45 |
50 |
|
Estimate |
估计这个任务需要多少时间，并规划大致工作步骤 |
45 |
50 |
|
Development |
开发 |
880 |
740 |
|
Analysis |
需求分析 (包括学习新技术) |
60 |
30 |
|
Design Spec |
生成设计文档 |
30 |
- |
|
Design Review |
设计复审 (和同事审核设计文档) |
10 |
- |
|
Coding Standard |
代码规范 (为目前的开发制定合适的规范) |
40 |
40 |
|
Design |
具体设计 |
60 |
80 |
|
Coding |
具体编码 |
400 |
510 |
|
Code Review |
代码复审 |
30 |
30 |
|
est |
测试（自我测试，修改代码，提交修改） |
250 |
200 |
|
Reporting |
报告 |
450 |
180 |
|
Test Report |
测试报告 |
300 |
370 |
|
Size Measurement |
计算工作量 |
30 |
- |
|
Postmortem & Process Improvement Plan |
事后总结 ,并提出过程改进计划 |
60 |
80 |
|
Summary |
合计 |
2690 |
2410 |
3.解题思路
一开始审题认为可能需要处理多条语句，考虑使用线程池来处理每个用户的请求，这样既可以封装用户的每个请求到一个request类里，还能有效防止线程过多造成的效率下降。考虑到控制台和图形界面都需要与管理线程的业务逻辑相分离，设计了一个RequestManager来管理所有请求。统计空格、行数、字符数都十分相似，分开为三个类，实现Counter接口，使得它们的结构更加规范，同时也使得增加新的Counter更方便，可扩展性提高。
实际开发过程中，从三个Counter的实现开始，让Request处理选项和文件，代码有点长，于是分开了两个方法来分别处理选项和文件。
文件方面，支持相对路径、绝对路径、当前目录下的同类型文件（*.txt *.c）输入
选项方面，支持 -l、-w、-c、-s
4.类的关系图
标签：路径 evel 效率 自我 table 封装 需求 nal hub
原文地址：https://www.cnblogs.com/littlehui3/p/11588650.html
