第四次作业-《结对编程》
fork仓库地址 | 地址 |
---|---|
github地址 | git |
结对伙伴学号 | 201731062518 |
结对伙伴博客地址 | 伙伴博客 |
1.结对过程
- 在明理楼的一个教室里一起对项目进行了分析。对项目进行分工,做了需求分析。一个项目开始于需求调研,所谓“千里之行,始于足下”、“好的开始是成功的一半”、做到事半功倍,有了好的需求分析,对于项目的顺利开展很重要,尤其是可以避免后期开发过程出现纰漏。然后讨论了要写多少类,我们一人负责一块,我负责接口方面,伙伴则负责调用方面。已经把类名、方法那些定义好了,这样整合起来代码能够跑起来。
在接口的设计过程中,我按照题目的要求设计了计算总字符个数、计算文本中总单词数、计算文本总行数、计算文本中每个单词出现的次数、将结果写入文件等方法,再最初的编码时,遇到了一些瓶颈,也是网上找方法、查资料,才解决了的。在代码复审的过程中,我和伙伴发现了我自己有些方法写的不是很好,逻辑上的处理有点瑕疵,然后一起商讨进行了改进。
然后参考了c#的代码规范,就开始了代码的编写,最后把两个人的整合起来,进行单元测试和结果测试,然后往GitHub上面迭代传送。
结对如下图:
2.psp表格
PSP2.1 | personal software process stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
planning | 计划 | 35 | 45 |
estimate | 估计这个任务需要的时间 | 65 | 60 |
development | 开发 | 50 | 60 |
analysis | 需求分析(包括学习新技术) | 15 | 15 |
design spec | 生成设计文档 | 10 | 15 |
design review | 设计复审(和同事审核设计文档) | 10 | 10 |
coding standard | 代码规范(为目前的开发制定合适的规范) | 5 | 5 |
design | 具体设计 | 20 | 30 |
coding | 具体编码 | 90 | 120 |
code review | 代码复审 | 45 | 60 |
test | 测试(自我测试,修改代码,提交修改) | 60 | 80 |
reporting | 报告) | 100 | 100 |
test report | 测试报告 | 45 | 50 |
size measurement | 计算工作量 | 20 | 20 |
postmortem&process improvement plan | 事后总结,并提出过程改进计划 | 15 | 10 |
3.解题思路分析
- 我们这里设计了一个count接口,以及count接口的实现类,再来一个调用类。最后再来一个单元测试类。接口里面有计算总字符个数、文件中总单词数、文本总行数、每个单词出现的次数、写入文件的方法。然后就是各个方法就是去实现项目所要求的基本功能。
- program类:调用接口实现类
- Count接口:定义方法
- count类:实现接口,实现其方法
- 程序流程图:
- 如何体现"Design by Constract"、"Information Hiding"、"Interface Design"、"Loose Coupling"等原则
- Design by Constract(契约式设计):按照某种规定对一些数据等做出约定,如果超出约定,程序将不再运行,例如要求输入的参数必须满足某种条件。
- Information Hiding(信息隐藏):是指设计和确定模块时,使得一个模块内包含的特定信息(过程或数据),对于不需要这些信息的其他模块来说,是不可访问的。
- Interface Design(接口设计):设计接口分析的角度要统一明确。接口的命名要规范。
- Loose Coupling(松耦合):松耦合的目标是最小化依赖。松耦合这个概念主要用来处理可伸缩性、灵活性和容错这些需求。同时意味着更多的开发以及维护工作量。
4.设计实现过程
- 1.Count接口中的方法
- 2.count去实现该接口,具体把方法实现出来
这里设计好后,和队友的整合起来。在自己桌面上创建两个txt文件,3.txt是读入文件,4.txt是写入文件。
运行后结果如下图:
5.代码复审
- 我们的功能是分开写的,所有没整合之前是不知道整合起来代码到底能不能能跑起来。代码的规范来说,我们两个人写的还是合乎要求,两个对代码进行互评,查找错误的地方。
- 两个整合过后,对代码进行运行,发现报了一堆错,可能是两个整合起来,对象名没一致,导致的错误。
- 有助于双方熟悉对方写的代码。
- 查到了自己的有些逻辑上的错误,同时队友还给出了优化算法的建议。
- 后面在cmd里面运行时发现输入命令后,并没有跳出正确的结果,才发现自己写接口方法的时候,没有写输出路径。这个是队友帮我发现的
- 代码规范(参考)--规范的代码
规范的代码可以提高开发效率。
养成代码规范的习惯,有助于自身的成长。
规范的代码可以降低维护成本。
6.单元测试
- 单元测试如下:
发现出错了,修改代码中assert.areEqual方法中的参数,成功通过测试,也成功读入测试的输出目录。
6.接口性能改进和测试
- 这里对接口进行改进,是我结对队友想出来的。设计一个抽象Statistical类,最后将具体词频统计的各个功能进行分离,使用工厂方法模式,将代码重构,方便了之后如果要增加其他功能,可直接添加其他具体操作词频的具体工厂即可,就无须整个改动代码。
- 性能测试
7.异常处理说明
- 假如在cmd里面输入非项目要求的命令,就会报错。我们这里使用了数组限制了输入的命令。
解决这里异常,我们可以使用try 和catch块提供得一种结构化的异常处理方案,try catch本身并不会影响系统的性能,在没有发生异常的时候try catch是不会影响系统性能的。受影响的时候是发生异常的时候。
8.附加功能
- 支持两种导入单词文本的方式:①导入单词文本文件,②直接在界面上输入单词并提交
提供可供用户交互的按钮和,实现-i -m -n -o 这四个参数的功能,对于异常情况需要给予用户提示。
将结果直接输出到界面上,并提供“导出”按钮,将结果保存到用户指定的位置。
结合博客要求增加的功能,这里我和队友对发布的要求的理解“提供可供用户交互的按钮和,实现-i -m -n -o 这四个参数的功能”应该就是设计一个可以供用户与系统交互的界面,也就是实现我们之前设计的cmd读入-i -m -n -o命令的效果。设计效果以及最终测试如下:
首界面:
导入文件:
结果如下:
9.上传github
- 在本地上往自己Github仓库先传入文件,提交了三次。
再签入老师GitHub。
10.总结
- 在结对的过程中还是有所收获的,虽然两个人的编码能力不同,我们还是积极探讨如何才能把项目做到最后,两个人各负责一个版块,最后再结合起来。这样做的话,前期要把需求分析做好,才能避免后面两人产生分歧。总体来说,我感觉我们可能做到了1+1=2,恰到好处的那种,两个人在最终的整合阶段,相互给对方写的版块提出一些改进上的建议。这次结对编程我也学到了很多,要做到前车之鉴,不能盲目的就直接开始敲代码;两个人要熟悉对方的工作方式,要团结一致,互相激励,遇到问题一起分析解决。