末日时在做什么？有没有空？可以来结对吗？
在软工课寻求AK是否搞错了什么？——结对项目第Ⅱ阶段
| 项目 | 内容 |
|---|---|
| 教学班级 | 2021春季软件工程（罗杰 任健） (北京航空航天大学 - 计算机学院) |
| GitLab项目地址 | 2021_Xiaodong_Lu-Pengyang_Xie_pair_work |
| Mokoghost学号后四位 | 3647 |
| duckingss学号后四位 | 3054 |
结对编程体验
Mokoghost
经历了第一阶段的结对，我们大致对校内能通宵自习的位置都摸熟了，每次去共享空间刷夜写代码还能碰见其他软工组的胖友😅
结对编程嘛，体验只有一个字：肝。和上次的不同在于——更肝了。想到自己充实的大学生活，不禁露出了欣慰而知足的笑容。
在看过其它同学上次结对编程的博客后，我们发现了Code with me这个好东西，极大地避免了git繁复的操作，而且也不需要我们挤在一个人电脑前分析代码了，它甚至支持视频通话，我们不得不震撼于IDEA的强大。虽然可以远程工作，但是能在现场交流更方便直接，我们在编写代码前总会进行充分的讨论分析，并且把每一条指令都过一遍，思考实现的方式（不过本次作业我们低估了文件系统实现的难度，许多指令的实现细节需要繁复推敲，指导书中模糊的表述也给我们造成了极为重大的困难）
duckingss
在第二次结伴中，由于前期设计不明确，负责写文件系统的L同学进度过慢，导致出现线程阻塞的问题。回顾分析整个结伴流程，我觉得我们有以下几点总结。
分析规划
对于分析规划，对比两次结伴，我们小组实际上都还是有进步空间的。第一次结伴作业中，在分析规划方面，我们花费了一个下午和晚上的时间来进行需求分析，代码结构设计，在分析规划阶段就实现了MYFileSystem内部函数的逻辑，在编码阶段就只需要实现File，Dir还有Parser类内部接口即可，编码实现阶段异常顺利，然而这样的坏处在于效率不高，整个开发阶段并行部分很少，大部分时间是串行，而且在规划阶段就将FileSystem类内部的具体逻辑实现也没有必要。
在第二次结伴中我们前期讨论的时间虽然不短，但是还是有一些架构的问题没有讨论清楚，比如不同文件的clone的行为，原子行为等问题。导致编码过程中出现了许多反复修改，当然，这也和指导书指代不清有些关系。
分析规划实际上是后期编码的一个框架，前期分析规划和后期编码时间是一个负相关，最佳的分析规划应该是找到两个函数时间和的最小点。总管两次结伴，我们也总结了一些分析的经验。首先,分析规划阶段最重要的是要捋清楚需求，在本次作业中即明确不同函数的行为，在捋清需求时，可以通过在指导书上作标记等方式进行标注。其次是架构的设计，在大致清楚需求的情况下对结构进行设计，我们认为相关设计未必要具体到接口逻辑，大致到函数调用关系上即可，可同时在在IDE内实现接口。这两个任务实际上是有一定耦合的，可以同步进行。
-
单元测试
在单元测试上，我们这次编写了大量的单元测试代码。由于本次实验设计细节较多，通过单元测试编写确实对于调试代码非常有帮助。同时我们发现除了保证代码完整性外，编写单元测试对于梳理代码逻辑有非常大也非常大的帮助，代码编写相当于站在编写者的角度，单元测试则相当于站在用户的角度来进行思考。我们这次X同学编写了L同学编码部分的大部分单元测试，编写中有很多指令组合是L同学没有想到的，如果让L同学来编写则会囿于编码逻辑导致单元测试效果一般。另外L同学认为对于一些复杂函数，也可以在需求分析阶段通过编写单元测试的方式来进行逻辑梳理，特别是对于本次文件接口全部确定的方式下。
-
时间安排
在本次结伴中我们有几天熬夜到了非常晚，任务量大和想一口气写完是主要原因。然而实际效果并不佳，在持续熬夜下两个同学的精神状态都不太好，特别是L同学在思路不太清晰的情况下debug效率非常低。实际上有效的睡眠对于高效工作非常有益，L同学认为如果大脑已经有点晕的情况下应该去休息，而不是继续编程。也许明天一觉醒来就很快把问题解决了。一个同学卡住时，另外一个同学可以做些其他的工作，应该要尽量保证并行，这样的效率才最高，而不必双线程阻塞在一个点。这次X同学在L同学编码未完成时就在进行单元测试的编写，为后期debug助力。同时我们认为结伴编程方式可以灵活，未必要一直两个人同时在一起编码，在debug等后期阶段使用code with me+线上的方式效率也不低。
功能拓展与代码迭代
第一次作业我们完成了一个简单的文件系统，基于第一次的思路，我们决定写一个对等的用户系统，并利用单例饿汉模式，实现一个Manager类来管理控制两个系统之间的通信。架构的设计十分直接，但是细节上有很多难点，尤其是软硬链接，有众多问题需要考量，我们总是会想到一些指导书中疑似没有指明的情况，由于指导书规定的行为与Ubuntu系统有所不同，我们很难自己找到答案。
PSP 规划
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | ~10 |
| · Estimate | · 估计这个任务需要多少时间 | 10 | ~10 |
| Development | 开发 | 1360 | 2190 |
| · Analysis | · 需求分析 (包括学习新技术) | 300 | 180 |
| · Design Spec | · 生成设计文档 | 30 | 0 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 10 | 120 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| · Design | · 具体设计 | 300 | 480 |
| · Coding | · 具体编码 | 500 | 600 |
| · Code Review | · 代码复审 | 60 | 60 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 180 | 740 |
| Reporting | 报告 | 120 | 150 |
| · Test Report | · 测试报告 | 30 | 60 |
| · Size Measurement | · 计算工作量 | 30 | 30 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 60 | 60 |
| 合计 | 1490 | 2350 |
完成时间：3月29日21：30-3月30日1：40，3月30日8：00-12：00，14：00-18：10，19：40-3月31日6：00，9：30-12：00，15：00-17：00，17：00-22：30（单人），22：30-4月1日1：00，4月1日零散时间较多，无法统计，合计：39h10min左右。
