结对编程总结——温故知新
作者：互联网
一、作业链接
二、博客推荐
结对编程项目已经落下了帷幕，同学们在博客中都进行了自己的反思和总结，相信大家在三周的时间里都有所收获。
所谓“三人行必有我师！”在我们评阅结对作业的博客过程中，整理出了几个小组的博客，他们的结对编程博客不仅内容丰富，还充分结合编程过程分析得失，现分享给大家共同学习！（选择带有助教的主观性，不可否认其他的博客同样有着精彩之处！）
推荐一
- 该小组的反思内容非常丰富，充分结合结对编程过程，给出了对于需求、架构、进度的反思分析。对于【在项目的更迭中如何保持良好的记录而不至于因为需求更改忘记细节】这个难题，该组同学也给出了非常优秀的答案：
我们假设的记录方式有二：一是在代码中作出记录，如注释、 TODO 代码块；二是通过自己项目的 issue 区，在记录自己的实现后，等待需求发生变化（issue 收到回应），然后本地进行修改提交。将假设进行记录，极大地方便了代码复审和对应需求改变进行的迭代开发。
- 通过issue记录TODO是一种很好的整理备忘的方法，也是接下来大家开展团队项目时课程组所推荐的安排工作任务的方法。该小组在梳理思路、分析需求、整理issue的流程可以让课程组及时看到大家的困惑与问题，也让其他小组供参考来测试自己的系统，不可谓不是惠己及人！
推荐二
- 文件系统的设计不仅仅要考虑功能需求的实现，也要兼顾运行效率。该组同学在实现了基本功能的基础上，对于文件系统的性能进行了更高的追求，他们对系统的三个方面进行了合理高效的改进优化，并给出了具体的设计思路与动机。该小组做到了兼顾实现的优雅与运行的效率，有兴趣的同学可以一探究竟——传送门。
- 该小组在第二次总结中提出了非常有深度的问题：MVP还是MBP？T 同学认为把结对编程看作是从MBP向MVP的思维上的一种转变的过程，并向课程组提出了：指导书应该在其中扮演什么样的角色？是要把每个细节卡的一板一眼，还是尽可能以简洁的语言表达最终想要做的结果？评测机又应该扮演什么样的角色？是盯着边界数据不放，还是强调功能的完备性？L 同学也提出了很多有价值的建议，比如指导书的编写能否参考既有文件接口标准（如 POSIX 等）。该问题激发了热烈的讨论交流，相信大家对此都有一个自己的答案——传送门。
推荐三
- 何谓需求分析，一上手就写代码为什么不可行不少同学在博客中提到第一次作业唐突。？该小组同学在事后分析中对需求进行了详细的拆解分析，将大需求拆解为中需求，中需求拆解为小需求，一步一步的进行需求分析，清晰明了，推荐大家去看一看。
- 进度管理也是大家的一个问题，我们发现有部分小组总是在最后一天压线提交。该小组展示了一个进度管理流程图，大家可以借鉴。在之后的团队作业中，大家需要把握团队整体的进度，防止部分同学掉队，有效的工具也不失为一个利器，推荐大家使用Gitlab的milestone和issue来管理团队的进度，相信大家在结对过程也其有所了解。
三、总结
- 首先感谢大家在本次作业中的辛苦付出！本次结对作业不论是从工程量还是软件开发的角度来说，都是一个不小的挑战，我们看到了很多同学积极地在issue区与助教讨论，并且完成优秀的博客作业，大家的坚持和努力我们都看在眼里，希望大家后续继续加油(ง •_•)ง！
- 关于结对编程，同学们在博客中对结对作业进行了反思总结。不少同学对结对编程有了新的认识和理解，改变了之前在博客作业中对结对编程的怀疑。在两人逐渐熟悉，能够互相配合并且了解彼此的习惯后，结对编程也会带来了1+1>2的效果；不过也有同学指出没有必要复刻教材关于结对编程的具体细节，找到自己的节奏更加重要，毕竟适合自己的才是最好的！总之，希望本次结对项目给大家带来收获！
- 关于单元测试，很多同学之前在博客提出疑问：单元测试为什么需要作者自己写？在本次作业，很多同学对此进行反思并且指出单元测试时遇到的问题：当系统复杂后，作者本人才能够做到抽丝剥茧，做到更加完备的逻辑覆盖（当然不适用于全部结对的小伙伴）。单元测试在大家后续的团队作业也是一个重要的程序质量保证手段。经过结对编程，相信大家一定能够更加灵活的使用单元测试！
- 最后，课程改革给大家带来了新的压力，但是我们的初心是希望给大家带来更真实的软工体验。改革必然面临着不确定性，希望大家能够理解因此导致的预期偏差，课程组会对大家付出的努力给予回报，期待大家在团队项目的优秀表现！
标签：同学,10,结对,总结,温故知新,编程,博客 来源： https://www.cnblogs.com/xiaomaoaichiyu/p/14688426.html