项目 | 内容 |
---|---|
这个作业属于哪个课程 | 2021春季软件工程(罗杰 任健) |
这个作业要求在哪里 | 结对编程 |
我在这个课程的目标是 | 学习并掌握利用软件工程的思想与方法构建大规模高质量的软件系统的能力团队协作能力等 |
这个作业在哪个具体方面 帮助我实现目标 | 结对编程开发,合作,对PSP进行亲身体验 |
Gitlab地址 | 学号后四位 |
---|---|
Gitlab地址 | 3407 3075 |
一、结对体验
结对编程照片:
3407:
本次结对编程与上次不同的是,我们使用了code with me
插件,共享项目实时合作编程。由于上次作业的经验,我们不用再纠结于CI等配置,工作量主要集中在面向指导书和issue的编码和测试环节。坦白说这次作业指导书虽然很详尽,助教回复也很及时,但是还是有很多很多的细节需要仔细分析敲定,在设计与测试方面消耗大量精力。
3075:
本次结对编程在设计阶段共同设计的基础上,在编码阶段使用了idea的code with me插件进行结对编程的工作。在编码的过程中,我们每个人负责编码的部分不同,一名同学编码时另一名同学负责帮忙监督。在结对编程的过程中,因为要写出让另一位同学也能很快地理解并反馈的代码,在某些自己增加的方法开始时,需要两个人同时敲定函数的接口再开始动手,同时也要保证实现方法的逻辑足够清晰,不能像之前自己一个人写代码那样随心所欲,只要自己能明白就分支乱飞。同时,在看别人编码时也会发现对方和自身实现思路上的不同,相当于用一种新的书写习惯和逻辑在写代码,是一种不一样的体验。但是由于本次的要求涉及的细节较多,再加上我们对于结对编程还不怎么熟练,导致编码阶段遗留下来很多细节问题,为了更正这些问题在后续测试阶段又花去了大量的时间,这方面还有待改进。
二、设计实现思路
UML图:
-
文件系统
-
对于原系统的一些修改
- 大小的计算方式——原本的文件和目录大小计算方式是将大小作为一种属性,每次修改后都会递归修改上层所有目录的大小。但是由于本次涉及到硬链接,一个文件修改会导致不止上册目录大小变化,所以将大小的计算方式改为每次访问的时候递归查询子目录和子文件,得到大小。
- 路径的获取方式——原本文件和目录的绝对路径在文件创建后是不会改变的,所以作为属性存储。但是本次指令涉及到了move和copy这种会修改路径的指令,于是将绝对路径的获取也改为了访问时再递归搜索上层目录来获取。
-
链接
本次作业新增了两种文件格式,软链接和硬链接。由于链接文件本质上都是文件,在某些操作的时候需要将其视为文件来处理,于是设计为两种链接都继承自
File
类。不过又由于链接文件的重定向操作,很多时候又不能作为文件来处理,所以只能说这样设计和将链接视作一种单独的结构相比各有优劣吧。- 软链接——对软连接的处理,将其的内容设置为其指向文件的绝对路径,每次需要重定向的时候得到软连接的内容,根据该路径进行搜索。文件删除后由于根据对应的路径找不到相应的文件,则会直接报错。
- 硬链接——对于硬链接的处理,设置一个属性
File linkedFile
,该引用指向硬链接链接的文件对象。随后所有需要硬链接重定向的操作都会返回对应的linkedFile
或者linkedFile
对应的属性。源文件删除后由于linkedFile
引用的对象没有被删除,仍能根据该引用访问。
-
move 和 copy
move和copy设计的大体思路是先找到对应src和dst,然后按照指导书上的一个又一个分支来解决细节上的问题。需要注意的问题是链接的重定向,然后mv和cp操作是视作修改src还是修改dst等。仔细看了看指导书和issue区,涉及的具体问题很多,设计文档里并不能详尽,具体的内容在编码的过程中体现在注释中比较妥当。
-
-
用户系统
用户系统的实现较为简单,指导书要求明确,按照要求设计并实现User、UserGroup、MyUserSystem
以及继承UserSystemException
的异常类和测试即可。
-
Manager实现文件与用户系统的交互
第二阶段指导书指出,文件系统与用户系统存在交互,比如
- 成功执行
exit
指令后,当前用户变更为``root,同时当前工作目录切换为
root用户最后一次执行
su指令时所在的工作目录(如存在,不存在时切换为根目录
/`),不输出任何信息。 - 若文件或目录
<dstpath>
存在,则输出形如create_user create_group create_time modify_time size count absolute_path
的信息,每个参数由1个空格
对此,我们参考了issue,注册了一个
static
的Manager
,在文件系统和用户系统创建时,加入到Manager
中,通过Manager实现``UserSystem和
FileSystem`的交互。 - 成功执行
三、PSP表格
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
Planning | 计划 | 10 | 10 |
· Estimate | · 估计这个任务需要多少时间 | 10 | 10 |
Development | 开发 | 1730 | 2030 |
· Analysis | · 需求分析 (包括学习新技术) | 40 | 30 |
· Design Spec | · 生成设计文档 | 40 | 30 |
· Design Review | · 设计复审 (和同事审核设计文档) | 20 | 20 |
· Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
· Design | · 具体设计 | 180 | 120 |
· Coding | · 具体编码 | 600 | 540 |
· Code Review | · 代码复审 | 240 | 60 |
· Test | · 测试(自我测试,修改代码,提交修改) | 600 | 1200 |
Reporting | 报告 | 50 | 50 |
· Test Report | · 测试报告 | 10 | 10 |
· Size Measurement | · 计算工作量 | 10 | 10 |
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 30 |
合计 | 1790 | 2090 |