结对编程_第一次迭代

项目 内容
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花费了比预计更长的时间。在编码前没有充分考虑细节方面的处理,例如解析路径、... 、这样特殊符号的处理,所以编码时间比预估的时间长很多。

posted @ 2021-03-25 16:31  Nebula007  阅读(161)  评论(4编辑  收藏  举报