个人项目WC(Python实现)

一、GitHub地址

https://github.com/hoka-17/WC

二、PSP表格

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	60	120
· Estimate	· 估计这个任务需要多少时间	60	120
Development	开发	1280	1500
· Analysis	· 需求分析	40	30
· Design Spec	· 生成设计文档	60	70
· Design Review	· 设计复审	30	20
· Coding Standard	· 代码规范	30	60
· Design	· 具体设计	60	160
· Coding	· 具体编码	600	650
· Code Review	· 代码复审	100	150
· Test	· 测试（自我测试，修改代码，提交修改）	360	360
Reporting	报告	190	170
· Test Report	· 测试报告	120	120
· Size Measurement	· 计算工作量	30	20
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	40	30
合计		1530	1790

三、解题思路描述

1、刚开始拿到题目后，如果是按照之前我开发项目的做法，就会直接打开pycharm进行编程。但是想到我做这个项目的初心是学习如何系统地
、科学地进行软件开发，于是在看完《构建之法》前三章后，先进行需求分析。

2、需求分析：首先看编程语言上没有限制，所以我选择了平时常用的Python。题目为实现一个统计程序来统计程序文件中的字符数、单
词数、行数、代码行、注释行。因为在之前做java课设时实现过类似功能，所以我很自然的想到可以通过正则表达式和通过Python自带的
read()函数、readline()函数结合进行计数。又因为它需要在命令行传入参数，而这方面我并没有怎么用过，于是到百度了相关库发现了
argparse库可以很方便的进行命令行参数的管理，于是我再去搜索了该库的API文档备用。还有一个功能是要求递归处理目录下符合条件
的文件，在这里我考虑了两种方法：一是通过检查文件名是否包含“*”和“？”，若有则进行直接在文件列表中搜索所有符合后缀名的
文件。二也是检测到包含“*”和“？”后，将传入的文件名构造为正则表达式去匹配文件。考虑到第一种方法虽然比较简单，但是并不
是很好的符合需求，故决定采用第二种方法。图形化界面要求能够选择文件，因为之前有编写过Python的gui，所以我也想到Python中pyq
t5库有相关函数可以调用。我将这些大概的思路记录下来，

3、通过以上分析, 我画出大概的程序运行流程图:

4、编程过程中，遇到如下影响深刻的问题：

(1). 在构建正则表达式进行统计多行注释行的过程，发现只有14行注释行的测试文件测试结果为69行，经过重新分析逻辑和与舍友进行讨
论，发现是因为使用的readline()函数，即漏考虑了多行注释行在一行的情况，经过修改测试无误。

(2). 在对一个包含中文的文件测试过程中发现在打开文件报错，查看后发现是文件编码问题，经过查阅资料有人建议将打开文件格式由u
tf-8改为ISO-8859-1，经过测试后发现没有报错。但却发现这样改后对于一个只有一个中文字符的文件进行测试，显示结果却是3个字符，
与舍友讨论后认为使用ISO-8859-1编码时一个中文字符会被认做三个码元，故会显示3个字符。这样与预期效果不符合，故只能重新想方法。
后又与舍友讨论后并测试发现是原来测试的文件不是用utf-8编码，故将测试文件转为utf-8编码成功运行无误。

四、设计实现过程

代码分为两个类，分别为功能类和界面类：

1. 功能类（WC)：实现了对文件进行各项统计功能，包含以下主要函数：

CountFunc(实现统计字符数、单 词数、行数、代码行、注释行)
RecursionPro(实现通过通配符处理目录下符合条件的文件)
main(调用函数)

2.界面类(Gui):实现通过图形界面选取文件，包含以下主要函数：

choose_file(实现监听按钮被点击后获取选择的文件，实例化一个WC对象并传递参数，通过main函数调用运行并将传回的数据显示到文本框)

各函数关系图：

五、测试结果

1. 功能测试

测试文件说明: empty.c(空文件)、OneChar.c(一个字符的文件)、OneLine(一行的文件)、OneWord(一个单词的文件)、SourceFile(普通代码文件)

(1). 基本功能:

(2). 拓展功能

(3). 高级功能

六、项目总结

1. 在进行项目编写时不能急于编写代码，而是应该多花时间再需求分析、代码架构上，只有先经过良好的设计，才能确保后面不会出现
   代码逻辑混乱甚至某些功能无法与原来代码耦合的情况。
   
2. 《构建之法》使我感觉受益匪浅，但我发现只看这本书是远远不够的，因为它只是指明了设计时思考的大致方向，但在进行详细设计时
   我还是感觉非常困难，很多地方不知道如何进行设计。因此未来应再去参阅其他有关构建的书籍，以及多编写项目以实践这些构建知识。