2021S软件工程——结对项目第一阶段

# 2021S软件工程——结对项目第一阶段

2021春季软件工程（罗杰 任健）

项目地址

1020 1169

---

## 1 结对感受

总体来说，结对编程与之前的个人编程感觉有很大的不同。有如下几个方面：

1. 在写代码的时候要慎之又慎，因为不仅要自己审核，也要面对同伴的审核，这是很重要的点。

2. 如何配合也是一个很重要的点。怎样把时间有效的利用起来，而不是在消磨在内耗、扯皮上。

3. 如果不能面对面编程，怎样利用好腾讯会议。

4. 不同于单人编程，怎样在结对编程中复审。

从我们结对的情况来看，因为是第一次结对编程，遇到了很多未曾设想的困难，我就想当然的认为：结对编程嘛，就是他带电脑，我拿键盘，他写累了我写，我写累了他写的编程，有什么的呢？

- 不思考整体框架，直接上手：

但是上手之后就不一样了，往往伙伴敲了几行，我就会问他：你创建这个变量什么目的？这个问题你打算怎么解决？我们该怎样设计类？该设计怎样的接口呢？你这个方法是打算怎么设计呢？调用几个变量呢？用什么容器呢？......全是这样细枝末节的事情，导致的就是双人编程效率奇低，因为没有写几行就被打断了。

而且，两个人的话，不怎么适合深入思考，想的都是——我怎么赶快给伙伴一个答复，然后就删了改、改了删。我认为，这是因为我们没有提前写好设计文档，直接上手编程，想着脚踩西瓜皮，滑到哪里算哪里。这在这样的小工程、小项目还比较好说，但是到了大工程、大项目的情况下，就有可能遇到推倒重来的问题。应当对于整个软件的大体结构、框架有初步的认识，再开始编程。

- 不写注释，可读性差：

此外，双人的结对编程，比起单人编程，更加强调代码的可读性。当我们编写代码的单元测试的时候，发现很多方法仅仅靠一个方法名来望文生义，是不够的了解这个方法是做什么的。导致进行单元测试的时候，我需要重读方法，需要了解这个的大体流程，然后才能编写测试样例。最终测试本身花费了不少时间。

主要原因，是没有写注释的习惯。可能我们的编程还停留在——“功能完成就行”的程度，毕竟之前都是那样写的，写注释也不加分hhhhh，时间还那么紧，哪有时间写注释？但是仔细想想，其实重读代码的时间，不见得就比写注释少很多。而且写注释这件事情，实在是功在当代，利在千秋。注释应当包含：创作者、联系方式、变量用途、方法目的、输入格式、大体实现方法之类的增加程序可读性成分的东西。养成写好注释的方法是我们需要总结的事情。

- 任务分配不明确：

这主要体现在两个人的编程水平不同，对于项目涉及的领域所了解的深度不同。导致一个伙伴“能者多劳”，另一个伙伴“紧抱大腿”（说的就是我）。目前来看，因为作业给的时间本身就比较紧张，小组也想赶快把作业完成，而且交给弱鸡去写可能又慢、bug还多，会耽误太多的时间，然后就出现了上面的问题。（ps：某个弱鸡找到了bug还不会改，改了还引入新bug，还是大佬亲自下手操刀解决的问题。）我觉得可能不止我们小组存在这样的问题（也可能确实我们小组的弱鸡太菜了），那么任务应当怎样的分配呢。

我想作为被动的一方，应当主动阅读代码，主动理解代码的功能，主动去写设计文档和单元测试，总结的时候也要仔细考虑后续的迭代，主动了解集成测试、主动了解怎么写单元测试。否则总是做这种紧抱大腿的事情不好hhhhh。

总体而言，目前来看，遇到的很大的问题就是以上所列举的。结对编程，或者是未来的团队编程，怎么做好交流是一个很重要的课题：怎样能够有效交流？怎样能够不浪费时间？

这些问题是我们之后的编程过程中会不断遇到、不断磨合的。而遇到这些问题总结的经验，可能在我们之后的生产实践中会用得上。

## 2 设计与实现思路

设计思路：

1. 将文件与目录的共性特征抽象出来，建立一个父类

2. 整个文件系统为树形结构，根节点即为根目录，每个目录/文件为一个节点，每个节点记录自己的父节点

3. 文件为叶节点、目录可以有子节点

4. 创建、删除操作即对文件系统树增加、删除节点

5. 对文件有特殊的写入操作

6. 文件系统类中记录当前所在节点，cd操作时更新该记录

实现思路：

根据以上的设计思路，抽象出了四个类：MyFileSystem File Directory FileOrDirectory，其中，FileOrDirectory 为File Directory的父类。

​

​

​

​

​

成员变量：

```java

private final String name;

private BigInteger size;

private final int createTime;

private int modifyTime;

private Directory prev;

```

方法：

```java

public int getModifyTime();

public void setModifyTime(int modifyTime); //在文件或目录发生变化时调用

public void setSize(BigInteger size); //在文件或目录大小发生变化时调用

public BigInteger getSize();

public String getName();

public Directory getPrev();

public void setPrev(Directory prev); //为根目录特殊设计

public String getAbsolutePath(); //获取当前文件或目录的绝对路径

public String getInfo(); //获取Info

```

​

​

成员变量：

```java

private final HashMap<String, Directory> subDirs;

private final HashMap<String, File> files;

```

​

方法：

```java

public void addDir(Directory subDir, int modifyTime);

public void addFile(File file,int modifyTime);

public Directory getSubDir(String name);

public File getFile(String name);

public boolean nameDuplicated(String name); //判断是否重名

public String getList(); //获取所有子目录和子文件

public void deleteFile(String name, int modifyTime); //删除文件时更新直到根目录的目录大小

public void deleteDir(String name, int modifyTime); //删除目录时更新直到根目录的目录大小

```

整体的uml图如下：

                                                                                                              |

| |

| ## 3 时间记录 |

| |

| | PSP2.1 | 预估耗时（分钟） | 实际耗时（分钟） | |

| | -------------------------------------- | ---------------- | ---------------- | |

| | Planning | 20 | 10 | |

| | ·Estimate | 20 | 10 | |

| | Development | 800 | 990 | |

| | ·Analysis | 30 | 120 | |

| | ·Design Spec | 60 | 20 | |

| | ·Design Review | 30 | 10 | |

| | ·Coding Standard | 10 | 10 | |

| | ·Design | 30 | 20 | |

| | ·Coding | 300 | 420 | |

| | ·Code Review | 60 | 30 | |

| | ·Test | 300 | 360 | |

| | Reporting | 120 | 120 | |

| | ·Test Report | 60 | 70 | |

| | ·Size Measurement | 30 | 20 | |

| | ·Postmortem & Process Improvement Plan | 30 | 30 | |

| | Total | 940 | 120+990+10 | |