结对编程_stage2
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 结对项目-第二阶段 |
| 我在这个课程的目标是 | 从实践中学习软件工程相关知识（结构化分析和设计方法、敏捷开发方法、软件测试、软件项目管理、软件开发工具和环境等），培养合作开发能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 实践结对编程，学习在 CI 中进行单元测试 |
| GitLab 项目地址 | 2021_Minyi_Xiao-Yulong_Xu_pair_work |
| 学号后四位 | 3377 3436 |
一、结对编程感受
3436：
本次结对编程跟上次类似，主要在寝室及新主楼公共区域线下进行。首先在设计阶段，两人一起一条条的看指导书，边讨论大体的解决方法，将整体框架商讨好后，由我先写好设计文档的框架（包括要有哪些类，方法及属性），然后一起对设计文档进行商讨修改。
因为有了第一次结对的经验，这次的初步设计还算顺利，但当讨论区各种问题频出，指导书也进行相应修改，才发现我们的设计做的不够细，有很多地方细节没考虑到，导致后来还大改了一次设计。
3377：
如果不是结对编程，面对这么多的边界情况和如此规模的系统，我无法想象需要怎么样和队友合作，才能够达成一致。
二、项目总体设计和实现思路
先上 UML 类图：
顶层接口 MetaFile 完成对所有文件（包括链接）和目录的归一化管理；AbsFile 继承这个接口，负责管理硬链接和狭义上的文件。
一个使用了单例模式的 Manager 类完成两个大系统之间的交互。具体地，Manager 类有以下特点和职能：
- 只能有一个实例
- 构造方法是
private的，由该类自身创建自己的唯一实例 - 通过
getManager()方法将唯一实例交付给MyUserSystem和MyFileSystem Manager类存有一个静态属性time，用于对指令流计数Manager类同时使用两个静态属性存储MyFileSystem和MyUserSystem的实例引用，MyFileSystem和MyUserSystem也都存有Manager的实例引用，使得二者可以间接访问彼此的一些属性。比如MyFileSystem需要查询当前用户时，只需要调用manager.getCuUser()方法，而manager.getCuUser()会调用myUserSystem.getCuUser()，从而返回当前用户名。
重定向的实现：
- 硬链接直接持有一个文件类的引用，而软链接除了基本的
MetaFile元信息只存储一个绝对路径。 - 对于硬链接的文件操作，可以直接调用
AbsFile中的接口，硬链接完成了对这些接口重写。 - 软链接不直接存储文件或者目录，而是存储路径，则文件目录进行各种删除、移动、恢复操作时，不需要额外操作软链接，就能够保证文件系统的一致性。缺点是当需要进行软链接重定向时，都需要从根目录开始根据绝对路径进行寻址，实现较为复杂，且异常的抛出非常繁琐。
困难很多，总体可以归结为系统的规模较大，以至于无论设计还是编码的过程都很漫长，且难以直视全貌，容易在边界情况上出问题，就连复盘都很困难。而隐藏在系统规模表面之下的，首先是难以找到合适的协作模式，但更大的问题是设计和架构的缺陷在规模增加时会迅速暴露。
三、PSP 表格记录
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 20 |
| · Estimate | · 估计这个任务需要多少时间 | 10 | 20 |
| Development | 开发 | 785 | 1615 |
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 210 |
| · Design Spec | · 生成设计文档 | 30 | 30 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 15 | 20 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 5 | 5 |
| · Design | · 具体设计 | 15 | 120 |
| · Coding | · 具体编码 | 420 | 810 |
| · Code Review | · 代码复审 | 120 | 210 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 120 | 210 |
| Reporting | 报告 | 45 | 60 |
| · Test Report | · 测试报告 | 20 | 20 |
| · Size Measurement | · 计算工作量 | 5 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 30 |
| 合计 | 840 | 1695 |
总体来说，由于系统复杂度的增加，产生了许多边界问题。如果不在设计阶段把边界情况完全吃透，导致架构与期望不符，就需要通过大量补丁完善系统；然而指导书本身更新了多次（非常感谢助教学长们的辛勤付出，澄清了数十条理解容易产生歧义的地方），且我们的能力不足以设计阶段把边界情况全部吃透，因此还是不可避免地进行了许多小重构和打补丁，同时产生了很多不敢处理的冗余实现（或许测试驱动开发在这个问题上表现好一些，不至于基本不敢修改不知道什么时候写下的看似无意义的代码）。
关于实践时间远远高于预估时间的的原因，初始的想法是：题目本身的设计容错比较低，一旦设计和标程存在少许差异，就容易产生大量补丁；但经过编程实践以及复盘以后，我认为并不是这样，归根结底还是初始的设计太烂了，如果有一个比较好的设计，即使和标程存在差异，也不需要进行如此多的特判，也就不会在编码和测试上花费远远高于预估的时间。
