一、作业链接
二、优秀作业推荐
本次博客作业虽然是简单总结，但是以下作业中都不乏有思考、有亮点的精彩内容，推荐给同学们阅读学习。
zzx 和 zzy 同学实现的文件系统的借鉴了 linux 文件系统的核心思想——一切皆文件，文件/目录都拥有一个索引节点(iNode)，其中文件 iNode 存储文件内容，而文件夹存储的是子文件列表，硬链接文件与一个普通文件共享一个iNode，软链接文件可以理解为一个存储了用于重定向的路径的文件。感兴趣的同学可以顺带去了解一下 linux 下是如何实现软硬链接的。
本文提出了非常有深度的问题：MVP还是MBP？T 同学认为把结对编程看作是从MBP向MVP的思维上的一种转变的过程，并向课程组提出了：指导书应该在其中扮演什么样的角色？是要把每个细节卡的一板一眼，还是尽可能以简洁的语言表达最终想要做的结果？评测机又应该扮演什么样的角色？是盯着边界数据不放，还是强调功能的完备性？L 同学也提出了很多有价值的建议，比如指导书的编写能否参考既有文件接口标准（如 POSIX 等）。感谢两位同学的积极思考和建议！
该组提出了两点非常好的优化设计，首先是COPY-ON-USE策略，可以做到在数据范围内通过所有的极限数据。
可惜由于时间原因没有具体实现。其次是
lazy tag，由于 mv 指令中，要求对全部子目录和文件的 modifyTime 进行修改，而暴力递归目录进行修改的复杂度是很高的， 使用lazy tag 可以省去不少没有询问 modifyTime 的时间 。之后使用 JProfiler进行了压力测试，看出优化效果非常明显。结对编程-stage_2
该组对于可能出现的极端数据，使用 JProfiler 进行了压力测试。并分析了测试结果，改进了相应代码以提高程序性能。![[BUAA2021软工助教]结对项目-第二阶段小结](/default/index/img?u=aHR0cHM6Ly9iYnNtYXguaWthZmFuLmNvbS9zdGF0aWMvTDNCeWIzaDVMMmgwZEhCekwzVndiRzloWkdWeUxuTm9hVzF2TG1sdEwyWXZUR3hVUm5remVtRlpXRlZ0Ylc5aU5TNXdibWNoZEdoMWJXSnVZV2xzLmpwZw== "[BUAA2021软工助教]结对项目-第二阶段小结")
三、总结
- 从本次结对作业的成果来看，同学们都在这门课上付出了不少努力，常常看到很多同学在半夜提出 issue、与助教进行讨论。课程组对同学们认真完成作业的态度表示敬佩。在高压力下完成代码时，同学们还能继续高质量地完成博客作业，这份坚持与执着值得充分的肯定！希望大家继续加油！
- 老生常谈——关于回复评论。部分同学没有积极回复博客，以后的每一次作业依旧会要求同学们积极回复博客，助教和老师也会努力和大家更多地做一些交流。对博客进行评论的目的，一是对博客内容提出建议，希望同学们能查漏补缺、拿到更好的分数；二是针对一些值得讨论的问题和同学们进行交流，这实际上是一个双赢的过程；三是表达对同学们认真完成作业的认可和鼓励。多和老师助教们讨论，不会耽误多少时间，也不会有什么坏处，而且还是让自己通过交流获得自我提升的一种绝好手段，因此希望大家还是可以积极回复博客评论。
- 关于结对方式。有不少同学在博客中如实反映，因为存在各种空间时间条件限制，很难完全实现 “一人写一人看” 的 “理想结对”，这有些遗憾。就去年线上课程的经验来说，场地限制并不足以构成实质性障碍。今年也有不少同学动手尝试了许多在线协作工具，可在两次结对博客评分的优秀作业推荐板块查收。在未来如有机会，希望同学们再去尝试一番，结对还是有其特殊的意义存在的，最起码可以让两者都在这样的伴随式协作中学到很多。
- 关于指导书的吐槽。很多同学反映第二次结对编程中指导书阅读起来比较费力，包括 “不再赘述” 、“指导书中该类型异常首次出现的位置越靠前，则它的优先级越高”，issue 数量较大且更新频繁等等，由此给各位同学带来的不便我们深表歉意。在撰写指导书时，我们的初衷是尽量简化同类的文字，压缩指导书的篇幅，希望给同学们的阅读带来便利，不会因为指导书的 “鸿篇巨制” 打消了大家的积极性。然而事与愿违，“不再赘述” 反而让大家反复搜索上下文可能提到的相似情况，“位置决定优先级” 导致大家需要集合第一次指导书确定各种异常出现的位置，这些隐藏在背后的工作量无形中加大了大家的负担，这也是我们并不希望看到的。课程组所希望的，是通过一个可以迭代开发、扩展性高、难度适中的选题，让大家感受结对编程之于以往的个人项目有什么优势或者劣势，而不是钻进细节本身，花过多的时间纠结于链接成环等特殊情况，这一点大家从讨论区中的 “同学们无需考虑” 和最后的强测数据点也可以看出。非常感谢大家对指导书编写的建议，这也帮助我们 “从用户中来，到用户中去”，改进指导书的编排，给同学们带来更加优质，更加有针对性的结对体验。
- 最后，改革的过程是痛苦的，但改革的结果可以是光明的，在此由衷地感谢讨论区中积极提问的同学，你们是此次结对项目改革的见证者，也是亲历者，更是创造者。请大家相信，课程组从来不会站在学生的对立面，更不会绞尽脑汁地从学生的身上夺走分数，我们的愿景是与同学们站在一起，让大家亲身感受到书本上的软件工程方法论在我们的实际体验下取得了什么样的效果，对自己是否有帮助。如果效果显著，我们就可以在未来的学习、工作中就去践行；如果效果甚微，不适合自己，我们可以进行充分的反思，分析其利弊得失，为以后的工作总结经验并提供方向。在后续的软工课程中，如果大家有对课程设计、教学方式上有建议或意见，欢迎大家及时和老师或助教沟通，大家一起参与讨论，这是解决问题最快、最简单、最行之有效的方法。
- 最后的最后，“芳林新叶催陈叶，流水前波让后波”，希望大家能够直面挑战，不消极，不懈怠，如 “新叶” 一般，像 “后波” 一样，冲破一切阻力，以锐不可当的气势不断向前推进！
四、评分规则
具体评分规则如下，对于超过10分的按满分10分计算成绩：
- markdown 格式清晰，便于阅读（1分）
- 要点是否完整（4分）
- 在博客开头给出教学班级和 GitLab 项目地址，以及结对的两个同学学号的后四位。（1分）
- 简单描述对于结对编程的感受，并给出两人开展现场结对编程的照片。如果还有采用其他的方式进行结对编程，也可以用照片或者截图等形式记录下来。（1分）
- 简单描述你对本项目程序的设计和实现思路。（1分）
- 采用下述PSP表格记录下你估计在程序的各个模块的开发上所需的时间和实际花费时间。（1分）
- 言之有物（6分）
- 描述结对编程感受部分有亮点（2分），例如：
- 对结对过程的描述详细生动
- 结合实际经历、有自己独立的思考结果，等等
- 描述程序设计和实现思路部分有亮点（2分），例如：
- 对程序设计进行了清晰且较为详细的描述
- 描述了单元测试的设计思路和实现过程
- 记录实现过程中的难点及解决方案，等等
- 在其他部分有亮点（2分），例如：
- 语言表达出彩、排版精美在
- 评论中与老师和助教进行了多次言之有物的交流互动
- 进行了要求内容之外的一些思考，等等
- 回复评论老师和助教的点评，并改进（1分）
- 及时回复，积极互动，作出改进（1分）
- 助教、老师在评论中提出了一些待回答的问题或改进的意见，但没有回复（-1分）
- 模板回复，如“谢谢老师/助教，我会努力的”（0分）
- 描述结对编程感受部分有亮点（2分），例如：
注：助教和老师都尽可能地对同学们的博客进行了评论。有一些同学完成作业的情况十分优秀，助教们只在评论中提出表扬，没有提出可供回答的问题，这些同学可能会在“回复评论情况”这部分评分得到0分。针对这种情况，在评分时一定会考虑到博客的整体完成质量，力求让同学们的工作得到一个合理的分数。
五、提交情况与分数汇总
1、本次作业成绩图
请使用个人学号后四位查询自己的分数（本次博客作业成绩取两位助教打分的平均值）：