软工第二次结对编程
结对编程第二周总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 结对项目第二阶段要求 |
| 项目地址 | 结对作业仓库 |
| 小组成员1 | 3676@力理利丽黎 |
| 小组成员2 | 3821@cyy369 |
结对编程感受
3676
呼，“在实验的初始阶段，绝大多数小白鼠都是极其痛苦的”。我觉得这句话可以非常合适的概括我现在的处境。
但首先，我要非常感谢我的队友。由于我们之间的空余时间本身不多，而且这周我还有其他的比赛要参加，所以我们在测试和debug阶段都是分开工作。在这个阶段的任务，有很多细节上的coverage都是他来完成的。
本次工程细节非常的多，要考虑的地方很细很杂，感谢助教对我们无休止的issue进行耐心的答复！
回到刚刚那句话，本次结对编程体验并不好。不好在于花费的时间过多。我并不认为是因为我们的能力不足而导致时间大幅。诚然，工程量大，工程细节复杂的开发测试时间一定会很长。但是这涉及到一个问题，我在这个项目上花费如此多的时间是否能够得到对应的回报。我在这周仅剩的吃饭时间思考了这样的问题，得到了我开头所想的那句话：“在实验的初始阶段，绝大多数小白鼠都是极其痛苦的”。
从大的方向上来讲，软工课程改革一定会需要花费大量的人力和时间成本。世界上任何一门优秀的课程都是经过无数老师和学生打磨而成的。我很庆幸我参与到了这个过程当中，但正如我所说，这个过程很辛苦，甚至是痛苦。当然，我能够理解并理性的看待这件事情，但这并不代表我很支持这样的高强度高花费的作业，即便“梅花香自苦寒来”。
3821
总的来说，这次其实真的不算一次很好的结对体验。
首先细节方面，指导书有很多细节不太清晰，虽然助教们都很及时解答网站上的各种issue，但是首先指导书本身确定的细节和要求就较多，需要仔细的思考和理解，这会极为的消耗时间，同时还得根据讨论区的各种issue对照的查看实现，继续进行一定的修改。细节理解以及代码实现部分相互交织进行导致进度不会很快，而且容易和队友在理解上出现分歧进而再解决同样也会消耗时间。
然后，由于这次作业的细节过多导致需要的时间精力较上次有更大的消耗，导致此次作业的战线非常长。这就引发了一个非常严重的问题，一个是自己的时间需求较大，另一个是自己和队员时间协调存在问题。上次作业接近二十小时的公共可用来同时进行的结对时间已经是协调的大部分自己事情的结果了，但是到了这次作业，直接超级加倍的作业，我们的时间协调就出现了问题。前期我们还能延续上次的形式进行面对面进行结对编程，但是到了后期，我们用来结对编程的时间就出现了不一致，但是不仅存在空间差而且存在时间差，就需要额外时间来进行同步，于是本就不低的时间量就又增加了……（我相信很多朋友们都是通过熬夜通宵的形式来进行的结对的，但是我们考虑到了自己的作息时间以及保证第二天的其他事宜的顺利进行，就并没有以通宵的形式进行结对，就导致了这种情况的出现）。而且由于我们这周都有很多其他的必要事情进行处理，于是对于大作业量的软工结对来说，既有点吃不消，而且整体的体验都不是很好，就和第一次结对编程的那种收获和体验差距真的很大。
设计与实现思路
总体思路
将第一作业整合进fileSystem包中，将此次作业新增的用户和用户组相关整合进userSystem包中，作为两个相对较为独立的系统进行代码编写和运行。
userSystem包
建立MyUserSystem类继承官方结构，新增MyUser类、MyUserGroup类和MyCheckName类。
MyUser类
该类需要存储自身的名字，自身对应的主组对象，以及自身所属的附属组的所有对象。当建立一个user对象时，即进行名字和主组对象的设置。删除时可通知各附属组对象来将自己删除。
MyUserGroup类
用户组对象大体和用户对象相似，需要存储自身的名字，自己所包含的所有用户，以及一个自己是否是主组的标记。用户组对象可以非主组的形式创建，然后再设置为主组，其次当用户组对象被删除时，通知其包含的所有用户将自己删除。
MyUserSystem类
继承接口作为命令调用的入口，同时以map的形式存储所有的用户和用户组对象，当命令调用需要时可以直接从map中获得对应的用户或用户组对象。
MyCheckName类
此类仅有一个作用，即检查传入的Name的参数是否符合要求。我们考虑在于将几乎每个功能都需要用到的Name参数检查功能分离出来，以此减少程序的冗余和降低耦合。
Manage类
此类作为MyFileSystem类和MyUserSystem类的交互工具，根据讨论区的提示，以单例模式创建此类，在类中创建两个静态变量，分别指向MyFileSystem和MyUserSystem，交互时直接调用即可。
fileSystem包
沿用了第一次作业的大体架构，在MyFile类和MyPath类的基础上新建MySoftLink类和MyHardLink类，以此将目录、文件、软链接、硬链接作为四个单独的结构来进行存储和修改。
MySoftLink类
软链接存储内容为对应文件或目录的绝对路径，当使用时被判定为需要重定向，即通过存储的绝对路径进行搜索重定向。当搜索失败时即可认定对应文件被删除。
MyHardLink类
硬链接存储内容为被链接的文件或目录对象，当需要使用硬链接时直接返回所存储的对象即可。且当源文件被删除时，但由于链接中所存储的对象引用未被删除，则可以继续进行访问。
MyFileSystem类
首先根据指导书将第一次作为并未进行测试的细节点进行完善和修订。其次在四种不同文件目录类型的结构下进行代码的编写和测试。
PSP估计表
| PSP2.1 | Personal Software Process Stages | 预计耗时 | 实际耗时 |
|---|---|---|---|
| Planning | 计划 | 10min | 10min |
| *· Estimate | · 估计任务需要多长时间 | 10min | 10min |
| Development | 开发 | 1420min | 2120min |
| · Analysis | · 需求分析 | 90min | 120min |
| · Design Spec | · 生成设计文档 | 20min | 20min |
| · Design Review | · 设计复审 | 10min | 10min |
| · Coding Standard | · 代码规范 | 10min | 10min |
| · Design | · 具体设计 | 30min | 60min |
| · Coding | · 具体编码 | 500min | 720min |
| · Code Review | · 代码复审 | 60min | 80min |
| · Test | · 测试（自我测试，修改，提交） | 700min | 1100min |
| Reporting | 报告 | 110min | 100min |
| · Test Report | · 测试报告 | 60min | 40min |
| · Size Measurement | · 计算工作量 | 30min | 20min |
| · Postmortem & Process Improvement Plan | · 事后总结，提出改进计划 | 20min | 40min |
| 合计 | 1540min | 2230min |
