结对项目第一阶段总结(陈源-郭屾)
项目 | 内容 |
---|---|
教学班级 | 2021软工 |
项目地址 | gitlab |
结对成员后四位学号 | 3665 |
结对成员后四位学号 | 5013 |
一、项目要求
本项目的主要任务是采用结对编程的形式完成一个简单的文件管理系统。
本项目将采用基于Gitlab CI的测评系统,使用手册见: 评测系统使用手册
项目第一阶段的要求请参见第一阶段指导书:第一阶段指导书
本次项目采用了OO课官方包的形式,第一阶段官方包见:官方包
二、结对感受
我们觉得两个人结对做项目分工很明确,陈源同学负责项目实现,郭屾负责单元测试阶段,最后博客由我们共同完成。结对的过程中,我们互帮互助,通过阅读伙伴的代码,感觉对我们自己的编程能力也有了一定的提升,对于一个难点,我们也进行了共同的讨论。进行的形式有线上和线下,线上交流居多,但是线下交流更加方便,能更快解决问题。总的来说这次结对还是很有收获,相处很愉快。附上结对照片
三、程序设计和实现思路
本项目需要我们管理的实体主要是文件和目录。分析我们需要实现的几个功能之后,我们这样设计:
我们有单独的文件类与目录类:首先是文件的基本信息:名称,内容,创建修改时间,为了方便向上更新size,又加了fatherDir这一属性,其指向该文件的父目录。目录类的基本属性与文件类基本一致,但目录类需要存储其子目录与文件,所以给他加了两个HashMap用以通过name映射子目录和文件,并且目录要经常判断是否重名,并且要按照字典序输出所有文件和子目录,所以又给目录类增加了一个TreeSet用来存放所有的目录名和文化名,判断是否重名和字典序输出都可以直接完成,优化了时间复杂度(应该可以直接用TreeMap存储文件和目录,不需要另外建立一个TreeSet,但是这一字典序输出就要归并输出,我嫌麻烦)。目录还保存了其对应的绝对路径,这样方便每次进行相应的输出,并且在remove方法里面可以通过startWith方法快速判断要删除的目录是否是当前目录的上级目录。每个目录和文件都保存了其对应的父目录指针,这样在文件更新size的时候,就可以按照这个父目录指针循环向上更新直到根目录。下图是UML。
可以发现这两个类有许多重复的属性也有一些重复的方法,所以我在最初考虑为这两个类建立一个共同的父类,方便info相关方法的调用,但是后来又觉得其实没太大必要,于是就没有建立这个父类。
关于核心类FileSystem的实现,我首先在这个类里加了两个属性:rootDir和currDir,分别代表根目录和当前目录,这样,在大量的路径检索任务中,就可以根据路径的第一个字符是否是"/",来直接取得路径的起始目录。因为路径可能有许多分隔符连在一起,所以在将路径按照"/"split的时候需要将其中的空字符串全去掉,然后按图索骥即可。这部分路径寻找我将其封装成了一个单独的方法,根据路径返回需要寻找的目录或者文件,如果返回为空值,则不合法,可以直接报异常。但是后面在写其他方法的时候发现大多数方法都要基于这个路径寻找进行微调。
四、模块开发预计和实际时间
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 5 | 5 |
· Estimate | · 估计这个任务需要多少时间 | 5 | 5 |
Development | 开发 | 530 | 725 |
.Analysis | · 需求分析 (包括学习新技术) | 20 | 20 |
· Design Spec | · 生成设计文档 | 20 | 20 |
· Design Review | ·设计复审(和同事审核设计文档) | 5 | 5 |
· Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 10 | 5 |
· Design | · 具体设计 | 60 | 60 |
· Coding | · 具体编码 | 240 | 200 |
· Code Review | · 代码复审 | 60 | 180 |
· Test | · 测试(自我测试,修改代码,提交修改) | 120 | 240 |
Reporting | 报告 | 60 | 50 |
· Test Report | · 测试报告 | 20 | 30 |
· Size Measurement | · 计算工作量 | 10 | 10 |
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 10 |
合计 | 600 | 785 |