| 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，恰到好处的那种，两个人在最终的整合阶段，相互给对方写的版块提出一些改进上的建议。这次结对编程我也学到了很多，要做到前车之鉴，不能盲目的就直接开始敲代码；两个人要熟悉对方的工作方式，要团结一致，互相激励，遇到问题一起分析解决。