1. Github地址
https://github.com/S-TRAVELER/WC
2. PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 20 |
| · Estimate | · 估计这个任务需要多少时间 | 20 | 20 |
| Development | 开发 | 1370 | 1405 |
| · Analysis | · 需求分析 | 80 | 80 |
| · Design Spec | · 生成设计文档 | 60 | 50 |
| · Design Review | · 设计复审 | 30 | 45 |
| · Coding Standard | · 代码规范 | 20 | 30 |
| · Design | · 具体设计 | 60 | 60 |
| · Coding | · 具体编码 | 900 | 950 |
| · Code Review | · 代码复审 | 100 | 90 |
| · Test | · 测试(自我测试，修改代码，提交修改) | 120 | 100 |
| Reporting | 报告 | 150 | 140 |
| · Test Report | · 测试报告 | 60 | 50 |
| · Size Measurement | · 计算工作量 | 30 | 20 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 60 | 70 |
| Total | 总计 | 1540 | 1565 |
3. 解题思路
由于之前开发基本是在Linux上，看到题目需要exe，于是就计划在Linux平台上开发完基本功能，再兼容Windows平台。
3.1 跨平台
由于考虑了跨平台（Linux+Windows），所以选择了CMake+Qt 的组合；用CMake来实现跨平台的编译，Qt实现跨平台图形界面显示。
在源码中，除了Gui是Qt实现不需要自己考虑跨平台，其他的功能的实现均需要自己进行系统判断，再进行相应平台的操作。
3.2 程序基本实现
为了提高程序的可扩展性，对命令、选项解析器、统计器分别进行了松耦合的处理；使得选项解析器、统计器可以不同需求进行策略替换；命令通过继承的方式进行装饰，以增强命令的功能。然后，再构建一个单例的命令注册器，对命令进行管理（看到这里，你大概可以猜到命令注册器让这个程序可以同时支持多个命令，而不仅仅是一个wc），提高了可扩展性。
3.2 通配符的支持
通配符的实现思路是把通配符表达式转化为正则表达式，然后实现目录轮询器，然后进行递归遍历，把符合通配符的文件名作为参数进行回调。注：由于Linux的终端和Windows的CMD会对通配符进行解析，所以需要用双引号（Windows的是单引号）把通配符表达式括起来。
3.3 图形界面
图形界面是使用Qt来实现，Qt提供了比较美观的用户界面。
3.4 多语言支持（自定义为-L）
这个功能算是对统计注释行、代码行的选项(-a)的扩展。在实现题目要求的功能时，认识到不同语言具有不同的注释方式，可以让用户进行语言选择，然后再根据用户选择的语言的注释语法进行统计。
通过配置文件的方式，读入不同语言的注释语法，实现了在不需要重新编译的情况下对语言种类进行扩展。
四、设计实现
五、测试运行
5.1 输入不存在的文件
Linux:
Windows:
5.2 不选定文件
Linux:
Windows:
5.3 无选项测试
Linux:
Windows:
5.4 多文件测试
Linux:
Windows:
5.5 通配符测试
Linux:
Windows:
5.6 选项乱序测试
Linux:
Windows:
5.7 递归目录
Linux:
Windows:
5.8 图形界面测试
Linux:
Windows:
5.9 代码覆盖率
六、项目总结
本次项目选用C/C++作为开发语言、CMake+Qt作为开发工具、GCov\LCov做代码覆盖率检查。
本次开发努力遵循使用面向对象的思想解决问题，不断地考虑软件模块的层次，尽量降低模块的耦合度。在设计软件模块方面花的时间比较多。此外，本次开发兼容了Linux和Windows两个系统，在写兼容代码的部分也花了比较多的时间。
这次开发过程中使用比较多的回调，以提高代码的复用率，这也是自己比较满意的地方；但是还是存在不足，代码冗余度还是比较高。
原文地址：https://www.cnblogs.com/ZWJCNBLOG/p/11569859.html