一, GitHub 网址:
https://github.com/Clarazhangbw/Wc.exe
二, PSP 表
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
Planning | 计划 | 100 | 120 |
· Estimate | · 估计这个任务需要多少时间 | 100 | 120 |
Development | 开发 | 1080 | 1620 |
· Analysis | · 需求分析 (包括学习新技术) | 240 | 360 |
· Design Spec | · 生成设计文档 | 60 | 60 |
· Design Review | · 设计复审 (和同事审核设计文档) | 15 | 15 |
· Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 30 | 40 |
· Design | · 具体设计 | 40 | 40 |
· Coding | · 具体编码 | 720 | 1020 |
· Code Review | · 代码复审 | 30 | 25 |
· Test | · 测试(自我测试,修改代码,提交修改) | 30 | 60 |
Reporting | 报告 | 145 | 175 |
· Test Report | · 测试报告 | 90 | 120 |
· Size Measurement | · 计算工作量 | 25 | 25 |
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 30 |
合计 |
| 1325 | 1915 |
三, 遇到的困难及解决办法
困难描述:
由于较长时间没有接触到 java, 所以在编程过程中比如利用哪一类, 用什么方法实现哪一些功能, 甚至在语法上也出现了比较大的困难;
最初没有先构建好程序框架, 导致后面写代码时东一块西一块, 没有一个比较清晰的结构;
对单元测试和递归这一类的知识不熟悉;
做过哪些尝试:
在重温 java 上, 一方面是看回以前写过的代码, 另一方面是在遇到不懂的时候就翻阅书籍或者是百度;
对于程序框架, 流程图这些, 在几次较大的代码模块更更改改后, 决定放弃之前原先比较乱的代码, 重新梳理了一遍项目要求和各个模块之间的关系;
翻阅《构建之法》, 上网查看学习单元测试等知识;
是否解决:
对于 java 的重温还有代码框架上, 都在自己不断学习的过程中找到了感觉, 先规划后写, 这样在后期打码当中也会思路比较清晰; 但是由于到最后时间的不充分以及自己知识储备不充分, 对单元测试还是没有理解太清晰.
有何收获:
重温了很多关于 java 的内容, 比如构建图形界面, 输入输出流等; 对自己未来打码有大体的规划, 知道应该先计划, 再实施, 而不是兴冲冲就干. 然后虽然了解了挺多关于单元测试的知识, 但是运用起来还是有困难.
四, 解题思路
刚开始拿到题目的时候, 其实极度恐慌的. 首先是因为对 java 生疏了, 对于实现各个功能函数也不清晰, 所以在分析题目以及想该从哪里下手这里起步比较困难. 后来决定先解决好本质 java 运用问题, 重温之后再开始分析题目, 制定计划.
对与重温 java 上, 也不是盲目的看一些视频或者什么的, 我主要是看回以前自己做过的课设, 因为发现这个题目的一些功能跟之前做过的文本编辑器之间有一些相似的地方, 比如统计字符数, 单词数, 还有图形界面打开文件的一些操作.
有了基础知识储备后, 对项目需求进行分析.
首先是整体框架, 最开始没有想很多, 主要的思路就是先将各个功能分别实现了, 然后主函数调用这些函数去实现功能.
主函数: 用户输入命令, 判断是否需要通过图形界面选择文件来进行查看统计的操作, 再根据用户输入选择统计量调用 "功能函数"" 图形界面函数 " 来获取显示相应的变量值.
功能函数: 一开始比较懊恼, 就是我对整个程序代码的框架构建得不是很清晰, 停留在, 所有的功能, 比如统计字符数, 注释行数等扩展和基本的功能都放在一个函数里, 然后每一次用户选择统计某一个值, 都会调用功能函数, 功能函数把每一个变量值都计算完成后, 再将用户需要的那个值返回给主函数. 这样做的弊端就是, 程序执行时间较长而且有多余的计算, 遗憾的是, 我到了最后才发现这样做的弱点. 也为之后打码提供了一些经验教训.
-c,-w,-l 这些都比较简单, 用 read() 方法依次扫描文件内的每一个字符, 再根据字符, 单词特性做判断后累加就可以了. 对于统计单词这个比较麻烦, 最后决定标准就是, 只要两个字母及以上连续且该单词后面是个 "\n" 或者其他非字母字符, words++, 但是这样出现了一个问题就是, 单词量每次都会少一个, 因为在最后面的那个单词, 因为他最后没有任何字符, 所以如果一个句子没有句号, 那该句子最后那个单词就算不进去. 因此我增加了一个 Word 变量去控制, 一有连续两个字母字符, 单词数就加 1, 然后直到遇到下一个空格数才计算进行单词数累加操作.
-s 递归处理目录下的文件, 一开始对这个比较陌生, 可能是比较抵触吧一看到递归两个字就, 所以后面研究也学不出所以然. 今天突然知道了解决方案, 但是由于整个框架设置的不合理, 所以到最后没有办法大改框架后把该功能添加进去.
-a 这些特殊行的统计最主要就是规定, 了解好各种特殊行的划分依据, 细节问题比如说注释行是有分两种的, 一种是 /*,*/ 可分行写注释的, 另一种是 //, 所以要针对特殊情况进行特殊处理. 然后调用 readline() 方法逐行扫描文件内的每一行进行统计就可以了.
-x 图形界面函数: 先是在 CSDN 上重温会 JFrame,JPanel,JLabel 等 java 类, 掌握了继承 JFrame, 定义组件, 创建组件, 添加组件, 对窗体设置, 显示窗体, 设置监听等步骤之后, 针对需求需要设计代码. 在调用 JTextArea 类设置文本框组件的时候, 由于对 JPanel, 还有整个窗口的布局没设置好, 导致文本框一直没有达到预期显示效果, 通过查询百度, 找到了设置文本框的大小以及几种布局方式, 不断尝试后最后也成功达到了预期的效果.
单元测试: 创造基础的测试文件以测试代码. 翻阅《构建之法》了解了单元测试的重要性并上网查询了相关步骤.
五, 设计实现过程
wc 类: 包括一个函数 wc(File file), 该函数实现统计字符数, 行数, 单词书, 特殊行的基本和扩展功能. 调用该函数能够得出所有的统计结果.
gui0 类: 包括函数 gui0() 函数, 用户高级功能 - x, 当用户输入 - x, 命令时, 会出现选择文件框, 用户可以选择文件获得相应统计结果.
gui 类: 有 gui0 类衍生出来的一个类, 当用户选择文件后, 所弹出来的选择想要获得的统计数据的界面, 该界面允许调用 gui0 函数重新选择文件.
test 类: 该类为主类, 获取用户指令, 判断是否进入图形界面, 若不进入则通过获取用户选择的统计条件, 来调用 wc 方法去显示统计结果.
总的来说, 由于设计的时候对 Java 类和函数这些掌握的不清晰, 所以很多方功能都是放在一个类的一整个函数里头, 所以实现起整个程序的时候, 会出现很多没必要的复杂调用. 以下是我各个类之间的调用关系:
六, 测试运行
1. 测试目录
2. 程序启动
3. 基本功能
测试基本功能 - c, 测试文件为只有一个字符 "c" 的文档
测试基本功能 - l, 测试文件为只有一行 "you are so cute" 的文档
测试基本功能 - w, 测试文件为只有一个词 "cute" 的文档
测试扩展功能 - a, 测试文件为基本源代码文件
测试多个功能一起出现统计结果, 测试文件为只有一行 "you are so cute" 的文档
测试高级功能 - x, 图形界面打开文件并点击显示统计结果, 测试文件为只有一行 "you are so cute" 的文档
六, 总结
在本次项目完成前期, 我因为对 java 的学习不够充分, 很多 java 语法还有一些类, 构造函数之类的都忘了, 所以面对这个项目是手无足措的, 面对详细的需求也没有想法. 比如说看到统计字数, 脑海里只有一些以前做过的比较模糊的记忆, 不知道应该具体怎么写. 最后通过查阅资料和翻看以前自己写过的代码找回了一些感觉. 在重新学习 java 上也花了不少时间, 也警醒了自己之后要经常练习, 保持对代码的熟悉感.
本次项目我学到了很多, 首先当然是 java 的运用, 通过实操项目, 找回了一些比如说 I/O 流, 函数调用, 图形界面设计的知识. 同时也从 0 到 1 实现了一个程序, 从预估, 设计, 编码, 开发, 测试, 文档等流程中锻炼自己. 在 Debug 当中找自己的问题, 最主要的就是, 在开始项目之前要规划好项目期间每天的计划, 每天要规划好当天内需要解决的事情. 在开发的过程中, 随时记录自己出现的问题, 以便后续解决. 总的来说, 项目不仅增加了我对代码的熟悉感, 而且也吸取了很多流程要点问题.
在这次个人项目中, 我还有不足之处, 那就是由于我对递归处理文件这个知识点学习的不充分, 导致于在临近截止的时候才想出解决方案, 但是由于程序框架已经构建好, 而且不够灵活, 使得这个函数无法再插入我的程序里, 修改起来很麻烦, 因此没有实现 - s 功能. 也是一个遗憾. 另外一点就是, 在做项目初期, 对程序整体架构没有构建好, 所以导致后面经常出现大幅度的修改, 耗费时间长, 这是非常不好的习惯. 经过这次项目, 我也意识到自己的不足. 往后的项目中会先计划, 边测试边开发, 提高代码质量.
来源: http://www.bubuko.com/infodetail-3213291.html