结对编程_第一次迭代
项目 | 内容 |
---|---|
GitLab项目地址 | 2021春季软件工程(罗杰 任健) |
GitLab项目地址 | 项目地址 |
队员1学号 | 3567 |
队员2学号 | 3018 |
结对编程感受
队员1
这是第一次接触结对编程,对于一个人编代码一个人看的模式很不适应,感觉效率很低,远不如两个人分工完成,而且也受到一定的环境限制,很少可以面对面结对编程,所以也采用了一些线上的方法,如腾讯会议。这些是感觉不太好的地方。
体验感较好的地方是,两个人一起讨论可以很快的理清思路,其中有一个人对题目有不理解的地方可以及时询问队友,从而可以快速理解题目,提高效率。而且两个人的知识体系结构是有差别的,这样在具体实现某一具体问题的时候就有多种的思路,可以相互比较选择较好的方法实现,这样比一个人编程更能提高代码的质量。除了技术方面,结对编程两个人还可以相互监督,很好的防止了划水和卡ddl的发生。
队员2
第一次实践结对编程,开始阶段并不顺利,由于初步设计过程过于简短,导致集成效果并不乐观,产生了很多细节上的问题,但是在解决问题的过程中,双方对于编码过程中产生的问题能够很好的进行分析、对产生的bug及时复现并修复,从不同角度产生的疑问也一一得到解答,改善了因编码习惯不同而产生的不同代码风格,使得代码更具有可读性,在代码复审和测试过程中合作进行了测试,体会到了看待问题的不同角度,完善了代码功能。
在编码过程中,学习了CI评测以及单元测试相关内容,体会到了单元测试的优点,在修改代码后仍然能够使用已编写的测试样例来进行单元测试,极大地提高了debug效率。
结对编程开始得很匆忙,但是相互督促能够提高时间观念,让队伍收获共同进步。
现场结对编程
腾讯会议
设计和实现思路
在本地结对编程中,设计并实现了以及几个类:
Main:程序入口。
MyFileSystem:实现了FileSystem接口。
Dir:目录类。
File:文件类。
MyFileSystemException:继承了FileSystemException,用于抛出异常。
下面是项目的UML图
Dir
将问题中的目录抽象为Dir。
- 目录主要使用了树的数据结构,节点需要具有的属性有父节点和子节点。
- 根目录是树的根节点,在MyFileSystem初始化时即创建,其父节点是自身。
- Dir中维护下级目录使用
HashMap<String, Dir>
,同时还要维护本级文件,使用HashMap<String , File>
- 当目录的大小发生改变时,需要递归更改上级目录的大小,直到递归到根目录,一定程度上可以降低时间。
- 在ls操作,因为需要将目录和文件按字典序排列,所以使用
TreeSet
容器将下级目录名和文件名进行排序。 - 在删除目录时,仅修改父目录的modify_time,修改所有上级目录的大小。
File
将问题中的文件抽象为File。
- 文件主要是树的叶子节点,能够向上寻找所在目录,即其父亲节点。
- 文件内的多数方法在目录的方法内嵌套使用,实现了目录对所含文件进行相关操作。
- 文件大小的改变时将向上修改父目录,直到根目录。
- 每次修改属性Content都会重置文件的大小size。
MyFileSystem
实现了FileSystem接口。
- 存储了根目录headDir以及当前工作目录nowDir,同时在初始化该类的同时将当前工作目录指向根目录,完成了0号命令。
- 实现了解析路径的方法
finDir()
等,对每个路径可以找到最终的目录或文件所对应的对象,或者找到其父目录对应的对象,从而便于功能实现以及异常的抛出。 - 在各个方法中先找到希望操作的目录或文件,再调用目录类下的相应方法,若进行文件操作则继续调用文件类下相应方法,实现了较为合理的代码结构,使针对目录对象或文件对象的操作具有层次性。
- 实现了对命名异常判断的方法
testNameIfLegal()
以及判断在当前工作目录是否能够删除某目录的方法dirIfCanBeRemoved()
。 - 对于
info
功能,由于目录和文件都具有这条指令,所以先对其父目录进行解析,找到父目录的Dir,然后通过父目录的Dir中维护的子目录和文件集合判断这条指令是针对目录还是针对文件。
PSP表格
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
Estimate | 估计这个任务需要多长时间 | 10 | 10 |
Development | 开发 | ||
Analysis | 需求分析(包括学习新技术) | 20 | 25 |
Design Spec | 生成设计文档 | 30 | 25 |
Design Review | 设计复审(和同事审核设计文档) | 20 | 20 |
Coding Standard | 代码规范(为目前的开发制定合适的规范) | 30 | 40 |
Design | 具体设计 | 90 | 120 |
Coding | 具体编码 | 360 | 480 |
Code Review | 代码复审 | 60 | 120 |
Test | 测试(自我测试,修改代码,提交修改) | 180 | 300 |
Reporting | 报告 | ||
Test Report | 测试报告 | 30 | 30 |
Size Measurement | 计算工作量 | 15 | 15 |
Postmortem&Process Improvement Plan | 事后总结,并提出过程改进计划 | 20 | 25 |
合计 | 865 | 1210 |
预估时间与实际耗时差距较大,主要体现在,在需求分析阶段学习使用CI/CD花费了比预计更长的时间。在编码前没有充分考虑细节方面的处理,例如解析路径、.
、..
、这样特殊符号的处理,所以编码时间比预估的时间长很多。