软工结对编程_热身
软工结对编程_热身
| 教学班级 | 2021春季软件工程（罗杰 任健） |
|---|---|
| GitLab相关地址 | 2021_pair_work |
| 两位同学的学号后四位 | 3480@dxh，4216@js |
结对编程初体验
记得之前老师在上课时讲到结对编程时我对此不以为然，觉得如果两人思路比较相似时结对起来还是比较迅速的，但等到真正完成时却发现事情并没有想象中的那么简单。
在需求分析部分我与队友是共同分析题意的，过程也比较顺利，觉得两人的思路是基本一致的，在具体开发时，我们采取的也是课堂上讲授的 一人写，一人看（驾驶员与领航员） 的结对模式。在开发的开始，由于我们的代码习惯和编程风格都不太统一，所以在沟通交流过程中花费了不少时间。后来经过一番探索，我们决定轮流进行编码，不断进行角色互换以在最短时间内适应对方的风格，也能最大程度上锻炼个人的能力。
就具体实践来说，我们分别负责了文件模块和目录模块的类以及方法的编写，一个人在写的同时另一个人在旁边及时进行检查和纠错，有任何不明白的地方也会及时发问、及时交流。虽然这样的编程方式比个人独自敲代码花费的时间肯定会长一些，但在一定程度上保证了代码的质量以及团队的合作效率。在测试程序时，我们又分别测试了对方的模块，采取的同样也是结对方式。通过前期的磨合，在测试时两人的效率明显比编码时要提高许多，也能够更快地达成共识。
就整体来说，结对编程在前期的确比较痛苦，进展也很缓慢，但是后期熟练了之后我们都觉得很有收获，至少能够更快速地定位bug和发现问题，并且在此过程中也从对方身上都学习到了很多知识。
设计实现思路
在本次文件管理系统中，我们创建了 type 接口并使 file 类和 Contents 类实现该接口从而让后续判断时文件还是目录更加方便。
对于文件类，我们设置了名称、父目录、内容、绝对路径和相关时间等属性；对于目录类，我们设置了名称、父目录、大小、绝对路径、子目录及文件和相关标识符等属性。在整个文件系统中设置当前目录和根目录的属性。对于任何指令都首先使用 pathparser 的方法进行路径解析，再根据指令的具体操作实现文件、目录的增删改查以及抛出特定异常等操作即可。举例如下：
- 对于目录的递归建立过程，首先递归判断所有路径的名称是否合法，其次再递归向上建立所有不存在的路径，对于
.和..的处理要注意细节 - 对于文件的删除过程，要首先删除该文件父目录中对应的下属文件，再依次修改父目录的大小和其他相关属性等。
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 15 |
| · Estimate | · 估计这个任务需要多少时间 | 10 | 15 |
| Development | 开发 | 740 | 830 |
| · Analysis | · 需求分析 (包括学习新技术) | 30 | 60 |
| · Design Spec | · 生成设计文档 | 30 | 30 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 10 | 20 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| · Design | · 具体设计 | 60 | 90 |
| · Coding | · 具体编码 | 360 | 480 |
| · Code Review | · 代码复审 | 60 | 60 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 180 | 180 |
| Reporting | 报告 | 70 | 95 |
| · Test Report | · 测试报告 | 30 | 60 |
| · Size Measurement | · 计算工作量 | 10 | 15 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 20 |
| 合计 | 820 | 940 |
