结对编程
| GIT地址 | GitHub |
|---|---|
| 结对伙伴 | 张龙 |
| 伙伴学号 | 201831061421 |
| 伙伴博客地址 | 博客 |
一、PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 20 |
| Estimate | 估计这个任务需要多少时间 | 20 | 20 |
| Development | 开发 | 230 | 303 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 25 |
| Design Spec | 生成设计文档 | 20 | 25 |
| Design Review | 设计复审 (和同事审核设计文档) | 5 | 8 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 25 | 25 |
| Coding | 具体编码 | 120 | 150 |
| Code Review | 代码复审 | 50 | 45 |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 60 |
| Reporting | 报告 | 80 | 105 |
| Test Report | 测试报告 | 20 | 20 |
| Size Measurement | 计算工作量 | 30 | 35 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 50 |
| - | 合计 | 330 | 428 |
二、计算模块接口的设计与实现过程：
第一步：相关类设计
- 读取输入输出文件类IOfile用于定义用户输入/输出的文件名和路径；
- 主函数读取文件的类容并传向统计函数；
- 统计函数接受数组首地址遍历统计；
第二步：相关操作函数
- 在函数count中依次进行了统计文件内的字符个数、单词的个数以及有效行数，并将这三个数值存储在传来的另一个数组中，以便在主函数中直接输出这三个数值
三、代码复审
- 由于我们使用的是C++语言，参考该博客介绍的编程规范
- 总的来说编写的代码还是比较粗糙，仅仅停留在可以完成规定的任务之上
- 我们在审核代码的时候发现有些功能函数并没有完成要求的全部，比如四个字母不算一个单词，大小写算一个单词。解决方面我们是在读取文件后把每个字母都换成大写字母
四、性能分析
五、结对过程
- 结对中我充当领航员（Navigator）角色，张龙当驾驶员（Driver）角色。先是一起讨论做了大体类的设计和算法流程设计，接着张龙就开始编程。两个人编程还是比一个人来的效率高些，有问题一起讨论，错误也第一时间被指出，特别是一开始的讨论，就先定义和封装了几个要用到的函数，避免了后期推翻修改，提高了开发效率。不过缺点也是有的，就是一个人在编程的时候，另一个人不好打扰，默默地看，后面发现没有完全按照领航员的设计来实现。函数没有完全按照预期抽象出来，导致效能分析处有问题！设计当中的接口和新增功能未实现，但类图当中的设计将其抽象出来方便了后续的代码优化。
- 这次的体会真的很深，实打实的结对，两人分工合作完成一个看似不难的任务，实际执行过程中还是遇到不少困难，结对的最大好处就在此处体现：在遇到困难的时候总是可以通过提醒和讨论解决之！
- 两个人的合作总是胜过一个人埋头苦写代码的，通过两个人结对的交流和探讨，会比平常一个人设计节约了不少的时间。由于生疏在百度许多东西的写法上耽误了不少时间，导致进度有些被拖慢。领航员在这个过程中一直提醒着注意要点，把控整个程序的质量。但林静自我反思在这次结对当中存在的许多不足，编程能力的不足导致没有很好地实现“领航员”设计出来的实现方案，望以后更加努力，才能更好地结对编程出理想的作品！
