结对编程_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

总体来说，由于系统复杂度的增加，产生了许多边界问题。如果不在设计阶段把边界情况完全吃透，导致架构与期望不符，就需要通过大量补丁完善系统；然而指导书本身更新了多次（非常感谢助教学长们的辛勤付出，澄清了数十条理解容易产生歧义的地方），且我们的能力不足以设计阶段把边界情况全部吃透，因此还是不可避免地进行了许多小重构和打补丁，同时产生了很多不敢处理的冗余实现（或许测试驱动开发在这个问题上表现好一些，不至于基本不敢修改不知道什么时候写下的看似无意义的代码）。

关于实践时间远远高于预估时间的的原因，初始的想法是：题目本身的设计容错比较低，一旦设计和标程存在少许差异，就容易产生大量补丁；但经过编程实践以及复盘以后，我认为并不是这样，归根结底还是初始的设计太烂了，如果有一个比较好的设计，即使和标程存在差异，也不需要进行如此多的特判，也就不会在编码和测试上花费远远高于预估的时间。