| # 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 | |
