结对编程
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)角色。先是一起讨论做了大体类的设计和算法流程设计,接着张龙就开始编程。两个人编程还是比一个人来的效率高些,有问题一起讨论,错误也第一时间被指出,特别是一开始的讨论,就先定义和封装了几个要用到的函数,避免了后期推翻修改,提高了开发效率。不过缺点也是有的,就是一个人在编程的时候,另一个人不好打扰,默默地看,后面发现没有完全按照领航员的设计来实现。函数没有完全按照预期抽象出来,导致效能分析处有问题!设计当中的接口和新增功能未实现,但类图当中的设计将其抽象出来方便了后续的代码优化。
- 这次的体会真的很深,实打实的结对,两人分工合作完成一个看似不难的任务,实际执行过程中还是遇到不少困难,结对的最大好处就在此处体现:在遇到困难的时候总是可以通过提醒和讨论解决之!
- 两个人的合作总是胜过一个人埋头苦写代码的,通过两个人结对的交流和探讨,会比平常一个人设计节约了不少的时间。由于生疏在百度许多东西的写法上耽误了不少时间,导致进度有些被拖慢。领航员在这个过程中一直提醒着注意要点,把控整个程序的质量。但林静自我反思在这次结对当中存在的许多不足,编程能力的不足导致没有很好地实现“领航员”设计出来的实现方案,望以后更加努力,才能更好地结对编程出理想的作品!