结对编程总结——温故知新
一、作业链接
二、博客推荐
结对编程项目已经落下了帷幕，同学们在博客中都进行了自己的反思和总结，相信大家在三周的时间里都有所收获。
所谓“三人行必有我师！”在我们评阅结对作业的博客过程中，整理出了几个小组的博客，他们的结对编程博客不仅内容丰富，还充分结合编程过程分析得失，现分享给大家共同学习！（选择带有助教的主观性，不可否认其他的博客同样有着精彩之处！）
推荐一
- 该小组的反思内容非常丰富，充分结合结对编程过程，给出了对于需求、架构、进度的反思分析。对于【在项目的更迭中如何保持良好的记录而不至于因为需求更改忘记细节】这个难题，该组同学也给出了非常优秀的答案：
我们假设的记录方式有二：一是在代码中作出记录，如注释、 TODO 代码块；二是通过自己项目的 issue 区，在记录自己的实现后，等待需求发生变化（issue 收到回应），然后本地进行修改提交。将假设进行记录，极大地方便了代码复审和对应需求改变进行的迭代开发。
- 通过issue记录TODO是一种很好的整理备忘的方法，也是接下来大家开展团队项目时课程组所推荐的安排工作任务的方法。该小组在梳理思路、分析需求、整理issue的流程可以让课程组及时看到大家的困惑与问题，也让其他小组供参考来测试自己的系统，不可谓不是惠己及人！
推荐二
- 文件系统的设计不仅仅要考虑功能需求的实现，也要兼顾运行效率。该组同学在实现了基本功能的基础上，对于文件系统的性能进行了更高的追求，他们对系统的三个方面进行了合理高效的改进优化，并给出了具体的设计思路与动机。该小组做到了兼顾实现的优雅与运行的效率，有兴趣的同学可以一探究竟——传送门。
- 该小组在第二次总结中提出了非常有深度的问题：MVP还是MBP？T 同学认为把结对编程看作是从MBP向MVP的思维上的一种转变的过程，并向课程组提出了：指导书应该在其中扮演什么样的角色？是要把每个细节卡的一板一眼，还是尽可能以简洁的语言表达最终想要做的结果？评测机又应该扮演什么样的角色？是盯着边界数据不放，还是强调功能的完备性？L 同学也提出了很多有价值的建议，比如指导书的编写能否参考既有文件接口标准（如 POSIX 等）。该问题激发了热烈的讨论交流，相信大家对此都有一个自己的答案——传送门。
推荐三
- 何谓需求分析，一上手就写代码为什么不可行不少同学在博客中提到第一次作业唐突。？该小组同学在事后分析中对需求进行了详细的拆解分析，将大需求拆解为中需求，中需求拆解为小需求，一步一步的进行需求分析，清晰明了，推荐大家去看一看。
- 进度管理也是大家的一个问题，我们发现有部分小组总是在最后一天压线提交。该小组展示了一个进度管理流程图，大家可以借鉴。在之后的团队作业中，大家需要把握团队整体的进度，防止部分同学掉队，有效的工具也不失为一个利器，推荐大家使用Gitlab的milestone和issue来管理团队的进度，相信大家在结对过程也其有所了解。
三、总结
- 首先感谢大家在本次作业中的辛苦付出！本次结对作业不论是从工程量还是软件开发的角度来说，都是一个不小的挑战，我们看到了很多同学积极地在issue区与助教讨论，并且完成优秀的博客作业，大家的坚持和努力我们都看在眼里，希望大家后续继续加油(ง •_•)ง！
- 关于结对编程，同学们在博客中对结对作业进行了反思总结。不少同学对结对编程有了新的认识和理解，改变了之前在博客作业中对结对编程的怀疑。在两人逐渐熟悉，能够互相配合并且了解彼此的习惯后，结对编程也会带来了1+1>2的效果；不过也有同学指出没有必要复刻教材关于结对编程的具体细节，找到自己的节奏更加重要，毕竟适合自己的才是最好的！总之，希望本次结对项目给大家带来收获！
- 关于单元测试，很多同学之前在博客提出疑问：单元测试为什么需要作者自己写？在本次作业，很多同学对此进行反思并且指出单元测试时遇到的问题：当系统复杂后，作者本人才能够做到抽丝剥茧，做到更加完备的逻辑覆盖（当然不适用于全部结对的小伙伴）。单元测试在大家后续的团队作业也是一个重要的程序质量保证手段。经过结对编程，相信大家一定能够更加灵活的使用单元测试！
- 最后，课程改革给大家带来了新的压力，但是我们的初心是希望给大家带来更真实的软工体验。改革必然面临着不确定性，希望大家能够理解因此导致的预期偏差，课程组会对大家付出的努力给予回报，期待大家在团队项目的优秀表现！🐱🏍🐱🏍🐱🏍🐱🏍
四、评分细则
1、博客markdown格式清晰，便于阅读等（1分）
2、结对项目实践反思 (10分）
- 针对前面两个阶段中出现的问题，分析问题的特征、产生的根源和对质量的影响程度（2分）
- 总结结对项目中的需求分析实践体会，并分析哪些bug是因为需求分析不足而带来的（2分）
- 总结结对中的架构设计实践体会，描述通过改进设计来提高程序的性能改进的思路和方法，并分析哪些bug是因为架构设计不足（特别的，需求变化）而触发的bug（2分）
- 总结结对过程中的进度、质量和沟通管理实践体会，并分析哪些哪些bug是因为两个人的理解不一致而导致（2分）
- 提出建议：根据三个阶段的结对项目的实践经验，对如何更好的实施和管理结对项目提出自己的建议（2分）
3、CI工具的体验感想（1分）
- 通过这次结对编程，你对CI的使用体验如何？你对这一工具有何认识？
4、结对编程感想（对队友/自身的评价、过程中遇到的困难与收获、锻炼了哪些能力）（7分）
- 描述你们结对的方法、结对过程中遇到的困难与收获，结合自己的结对经历，说明结对编程的优点和缺点，分享可以推广的结对妙招。（2分，优缺点和妙招各1分）
- 评价你的队友，使用汉堡点评法评价你的结对伙伴，务必给TA 提改进意见。（2分：点评隔着一层纸给1分，实质的内容给2分）
- 描述在本次结对编程的过程中，你们使用了哪些软件工具，是如何应用于实践的。（1分）
- 描述通过本次结对编程的感悟和体会，对本次作业的有哪些想吐槽的，觉得本次结对作业内容可以在哪些方面做出改进？（2分）
5、博客评论回复并且改进
- 助教、老师在评论中提出了一些待回答的问题或改进的意见，但没有回复（-1分）
- 模板回复，如“谢谢老师/助教，我会努力的”（0分）
- 及时回复，积极互动，作出改进（1分）
注：助教和老师都尽可能地对同学们的博客进行了评论。有一些同学完成作业的情况十分优秀，助教们只在评论中提出表扬，没有提出可供回答的问题，这些同学可能会在“回复评论情况”这部分评分得到0分。针对这种情况，在评分时一定会考虑到博客的整体完成质量，力求让同学们的工作得到一个合理的分数。
五、成绩展示
1. 作业成绩千帆图
2. 本次作业成绩列表
|学号1|学号2|MarkDown|实践反思|CI体验感想|结对编程感想|回复评论|总分|最终成绩|
|:----😐:----😐:----😐:----😐:----😐:----😐:----😐:----😐:----😐:----😐:----😐:----😐:----😐:----😐:----😐:----😐:----😐:----😐
|1020|1169|1|7|1|4|1|14|19.6|
|1045|3298|1|10|1|6|-1|17|23.8|
|3004|3477|1|10|1|6|1|19|26.6|
|3567|3018|1|8|1|4|1|15|21|
|3019|3293|1|10|1|7|1|20|28|
|3808|3050|1|10|1|7|1|20|28|
|3647|3054|1|10|1|5|1|18|25.2|
|3075|3407|1|10|1|7|1|20|28|
|3080|3420|1|10|1|6|1|19|26.6|
|3110|3142|1|10|1|5|1|18|25.2|
|3146|3464|1|7|1|6|1|16|22.4|
|3357|3172|1|10|1|7|1|20|28|
|3197|3204|1|10|1|6|1|19|26.6|
|3201|3256|1|7|1|5|1|15|21|
|6161|3339|1|10|1|7|1|20|28|
|3439|3358|1|10|1|6|1|19|26.6|
|3377|3436|1|10|1|6|1|19|26.6|
|3480|4216|1|10|1|7|1|20|28|
|3580|3636|1|10|1|7|1|20|28|
|3584|3622|1|8|1|7|1|18|25.2|
|3665|5013|1|5|1|6|0|13|18.2|
|3821|3676|1|9|1|5|0|16|22.4|
|3812|3717|1|10|1|6|1|19|26.6|
|7155|5044|1|8|1|5|1|16|22.4|
|3148|无|0|0|0|0|0|0|0|
