2021软件工程结对作业--第一阶段
2021软件工程结对作业--第一阶段
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个班级 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ |
| 这个作业的要求在哪里 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ/homework/2638 |
| 我们在这个课程的目标是 | 培养工程开发能力和团队能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 进行结对编程实践，提高团队合作与交流的能力 |
| GitLab项目地址 | https://gitlab.buaaoo.top/2021_alige_homeworks/pair_works/2021_yue_chou-qian_liu_pair_work |
| 队员1学号后四位 | 3357 |
| 队员2学号后四位 | 3172 |
第一部分 结对编程感受
队员1
本次结对编程项目是我一次全新的尝试。在以往也有过不少的大作业是以“团队”的形式进行的，然而最后往往是以我写后端、你写前端之类的粗暴分工收场，完全谈不上一个真正的团队。而本次虽然只是两个人合作，但合作和交流的深度是之前的作业不能比较的。我的搭档是因为结对编程才认识的，作业开始前我还为能不能顺利开展开做，能不能有效的沟通而紧张。但是事实证明这完全是我多虑了，虽然一开始的交流存在一些理解的偏差（我认为这也是两个人合作的必经之路），为之后埋下了一些小隐患，但是我们迅速的就适应了对方的风格，愉快的开展了合作。说到这里我不得不感叹一下，由于之前学过的课程几乎一样，交流起来大家的思路基本上都是一致的，很快就能进入开发的状态。由于写出的代码还有另外一个人要看，在开发的过程中，我也注意着提高了对自己的要求，比如：该抽象出来的方法就抽象出来，方便复用，如果只是我一个人的话我有可能就ctrl c/ctrl v大法了（发现了结对编程的新作用，增强代码的规范性hhh）。除此，阅读搭档的代码也是一种新的学习。尤其是单元测试的环节，让我不能只是大致看一看，反而我需要仔细的阅读每一个分支、每一个异常，这也是一种锻炼。
除了以上的积极方面，我也认为结对编程也有一些小的问题，比如时间难以确定、计划难以制定（因为我很难估算搭档做一件事所需的时间，我搭档也是如此，因此最后我们决定根据开发的进度灵活安排而不是以时间表的形式）。
总结一下，我对本次结对编程的体验还是不错，也从我的搭档身上学到了很多的东西，同时有人在督促着我也减轻了我的拖延症，总体来看开发的过程效率还是很高的。
队员2
结对编程优缺点
缺点：相对于公司全职的程序员，在校学生并不是任何时候都能在电脑前写代码，两人的课表结构，生活习惯，其他作业任务量都不同程度上给合作的高效性，以及计划的完成度带来困难；这些因素也让理论上的”一个人坐在另一个人后面看着他写代码“变得理想化；编程习惯的不同也给合作开发带来一定的麻烦，很多bug都是由于信息不对称导致的。
优点：在相互熟悉并且明确分工之后，合作效率开始明显提升，同时由于"复查机制"的存在，逻辑漏洞上的bug在正式的测试前就被发现概率大大提高。
结对编程的收获
- 对于找出的自己的/对方的bug，指导书中的疑问都会及时与结对伙伴交流；
- 对于新增的方法会写上相对详细的注解，方便对方查错和使用；
- 学会了仔细阅读对方的代码，提取出自己能使用的部分，而不是"相互嫌弃"，然后"重复造轮子";
- 锻炼了合作与交流能力，这也是这个课程的目标之一
第二部分 项目设计分析
1.项目结构设计
1.1 问题分析
在文件管理系统中，主要有文件和目录两种对象。这两种对象的基本属性和操作大致相同，如：都具有创建时间、修改时间、大小、父目录等属性。因此，我们选择建立FileOrDir的抽象类，文件和目录都继承该类。对于目录和文件的操作，我们提炼出一条重要的方法——根据路径寻找目标文件（目录）。因此在编写课程组要求的方法之前，我们编写了findPath、updateSize、checkFormat 等通用方法，以便接下来调用。
1.2 UML图
利用IDEA导出的UML类图如下：
我们小组对于程序的结构设计是比较满意的，类与类之间的关系是比较简洁的，同时也考虑到可能的迭代功能预留了接口。
2.项目反思和总结
虽然项目最后的结果我们小组是比较满意的，但是在开发的过程中由于对结对编程模式和彼此的不熟悉我们也走了一些弯路。借此机会也对我们走过的弯路进行一定的反思和总结（希望也能帮助到有类似经历的人）
-
对于开发过程中可能用到的词汇含义事先说好：在设计阶段。我们需要讨论类和类的方法的基本结构时，我们使用了某某类的外面这样的说法，但是我们二人对外面的理解是不同的。我们一人认为外面指的是
MyFileSystem外，另一人认为是MyFileSystem内。于是就出现了以下的对话：- A：对size的更新我们就放在外面吧
- B：我觉得放在里面不是更好吗然而实际上我们两个人都认为应该放在
MyFileSystem内 - ......
然而实际上我们两个人都认为应该放在
MyFileSystem内，所以刚刚的一大段沟通都是无效的。因此事先说好或者避免使用指代不清的词汇一定程度上会提高沟通的效率。 -
技术上的细节及时记录。在对size的处理上我们达成了一致在
MyFileSystem内进行处理，但是我们只是口头达成了一致，没有记录下来。导致开发的时候我们不仅在MyFileSystem内进行了处理，在FileOrDir的抽象类中也进行了处理。但是我们两人都没有对这样的做法提出异议。测试的时候这一点就导致了很严重的bug，花费了我们很多的时间才发现，我们对size进行了重复的处理。令人啼笑皆非的是发现bug原因的时候我们都想起来了事先的约定。 -
修改接口定义时需要及时提醒搭档，并在代码中做出注释进行说明：在开发过程中，我们出现了对
findPath方法的参数进行了修改，但对方及时注意到也没有进行提醒。导致之前代码中对此方法的调用出现问题，才进行了充分的讨论，但是因为这个我们的程序中遗留下了一下未能及时修改的部分，在之后的debug中也花费了我们很多时间。 -
单元测试和debug双线并行：在编写单元测试和debug时我们没有严格按照一人编写一人审阅的方法，而是选择了每人负责一个方法。从我们小组的配合情况来看，单元测试帮助发现了对方没发现的bug，而debug也对单元测试没能覆盖到的边界情况进行了覆盖，起到了相辅相成的作用。
第三部分 PSP表格
| PSP 2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 45 |
| · Estimate | · 估计这个任务需要多少时间 | 30 | 45 |
| Development | 开发 | 600 | 760 |
| · Analysis | · 需求分析 (包括学习新技术) | 30 | 40 |
| · Design Spec | · 生成设计文档 | 20 | 15 |
| · Design Review | · 设计复审 | 10 | 15 |
| · Coding Standard | · 代码规范 | 30 | 45 |
| · Design | · 具体设计 | 60 | 60 |
| · Coding | · 具体编码 | 180 | 300 |
| · Code Review | · 代码复审 | 90 | 45 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 180 | 240 |
| Reporting | 报告 | 120 | 175 |
| · Test Report | · 测试报告 | 60 | 120 |
| · Size Measurement | · 计算工作量 | 30 | 30 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 25 |
| 合计 | 750 | 980 |
