| 教学班 | 罗杰、任建班周五3、4节 |
|---|---|
| gitlab项目地址 | Here it is. |
| 成员 | 周远航（3004） 李辰洋（3477） |
结对编程体验
经过了上一阶段的磨合，第二阶段我们的配合更加流畅，也熟悉了对方的编程习惯，因此编程的效率有所提高。
和stage_1不同的感受是，stage_2我们讨论的时间明显减少，项目的基本框架已经成型，因此无需像第一阶段一样对大型设计架构进行讨论，只需要关注一些细节功能的实现方式即可。另外，本阶段代码规模明显增大，为了保证代码的可读性和优雅程度，我们花了更多时间在代码美观上，包括对一些冗长的方法进行了重写，提取更多工具性方法和工具类等。
在开始动笔前，我们还是首先进行了面对面讨论，更深入地挖掘了linux文件系统的原理，并对各个新增功能的实现方式进行敲定，并在第一阶段的讨论结束后开始动手。
由于和队友的课程时间不一致，能面对面编程的时间宝贵且有限，考虑到本次作业usersystem和filesystem的独立性较大，我们进行了一定的分工，并在仓库的alpha分支进行协作，将稳定版本merge到master分支触发评测，以节约评测资源。
截至目前，我们二人已在两分支进行了共186次commit。
然后，现实是残酷的，在动手一天后，主笔usersystem部分书写的L同学已经顺利完成了所有功能的实现和test的书写。然而主笔filesystem部分的Z同学陷入了啃不动指导书的绝境。于是乎在一个月黑风高的晚上，我们又一次进行了面对面现场合作。
在后期测试阶段，我们通过书写单元测试发现了一系列问题，延续了第一阶段的测试导向编程方法，即将test编写好后传递给对方，对方修改代码后通过测试。
设计思路
在第一阶段文件系统的基础上，本次迭代要求实现HardLink、SoftLink以及mv、cp、readline等指令，以及新增了用户系统及一系列功能，本阶段程序设计框架如下UML图所示：
-
MyFileSystem
文件系统核心类，继承官方接口FileSystem。用于记录root和currentPosition两个目录入口，并且维护指令流计数器。
-
DirectoryEntry
目录入口类。用于管理目录下的所有文件（包括目录文件、普通文件）以及文件树的上下级关系。
-
File
抽象类，所有文件类型对象的父类，定义了文件类型对象的公共属性和方法。
-
RegularFile
普通文件，继承File抽象类。
-
Directory
目录文件，继承File抽象类。
-
SoftLinkFile
软链接文件，继承File抽象类。保存了指向文件或目录的绝对路径。
-
MyUserSystem
用户系统核心类，继承官方接口UserSystem。用于管理系统所有用户和用户组信息，记录当前系统活跃用户信息。
-
User
用户类。保存用户名、用户主组及其所属用户组等信息。
-
Group
用户组类。保存用户组名及其包含的用户信息。
-
Parser
路径分析及格式检查工具类。
-
LookUpService
文件查询工具类。
实现过程
在本次任务中，我们继续使用TDD（测试驱动开发）的开发流程，尽量做到在编写代码之前做好测试单元的设计和编写，然而由于本次功能涉及的条件和特殊情况判断多且复杂，也让测试单元的编写举步维艰。
在代码编写过程中，出现了不少需要纠结具体细节实现的地方，出于对性能的考量，本次任务中使用JProfiler对极限数据进行了测试。
代码复审和测试阶段，我们发现，在对深度极大的文件树进行操作时，可能出现性能上的瓶颈，于是构造了大量超深目录创建和文件写入的测试数据，发现出现了爆栈、爆堆区空间等情况。对于爆栈的情况，我们将部分递归进行的函数去递归化，采用循环的方式进行处理。而对于爆堆区空间的问题，有些一筹莫展，于是我们使用JProfiler监测运行程序的内存占用状况，发现仅仅一次深度递归的mkdir，就产生了大量的内存占用：
右图中可以发现，Object[]的size达到了462MB，这让我们想到，为了让绝对路径不进行重复计算，我们对每个目录都使用ArrayList对路径中节点进行保存，但缓存机制除了占据巨大的内存，还有另一个缺点，速度：
可以看到，对当前目录ArrayList的计算中，需要使用addAll方法将父节点的路径列表加入当前节点，这不仅占用了大量内存，也在计算的速度中，并不讨好，因此，我们计划使用StringBuilder保存，虽然在速度上有所进步，但内存空间上的消耗大了将近1/3：
最后，我们分析，这种缓存虽然在计算上不需要过多时间，但如果存在大量的新增、移动、复制等命令，将大大降低运行效率，并且内存的使用量永远是一个隐患，因此，我们最终放弃缓存机制，对绝对路径的计算，仅采用即时计算的方式：
最终发现，在这种情况下，内存的使用量和速度都达到较好的水平，但在大量的getAbsPath方法调用中，可能依旧存在速度问题。鱼和熊掌不可兼得。
时间规划
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟 |
|---|---|---|---|
| Planning | 计划 | 20 | 20 |
| · Estimate | · 估计这个任务需要多少时间 | 20 | 20 |
| Development | 开发 | 555 | 815 |
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 90 |
| · Design Spec | · 生成设计文档 | 15 | 15 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 10 | 10 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| · Design | · 具体设计 | 30 | 30 |
| · Coding | · 具体编码 | 180 | 240 |
| · Code Review | · 代码复审 | 120 | 150 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 120 | 270 |
| Reporting | 报告 | 60 | 60 |
| · Test Report | · 测试报告 | 20 | 20 |
| · Size Measurement | · 计算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 636 | 895 |
整体来看，设计和主要代码的编写过程依然比较顺利，但代码复审、研读指导书细节、修改细节实现、测试复杂情况花费了比预计多了不止一倍的时间。而且，这些时间并不是集中的，而是遍布了作业进行期间的每一天。