一：Fork仓库的Github项目地址
| PSP2.1 |
Personal Software Process Stages |
预估耗时（分钟） |
实际耗时（分钟） |
| Planning |
计划 |
120 |
95 |
| · Estimate |
· 估计这个任务需要多少时间 |
20 |
17 |
| Development |
开发 |
60 |
52 |
| · Analysis |
· 需求分析 (包括学习新技术) |
30 |
36 |
| · Design Spec |
· 生成设计文档 |
20 |
18 |
| · Design Review |
· 设计复审 (和同事审核设计文档) |
15 |
15 |
| · Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
15 |
15 |
| · Design |
· 具体设计 |
60 |
78 |
| · Coding |
· 具体编码 |
70 |
66 |
| · Code Review |
· 代码复审 |
30 |
26 |
| · Test |
· 测试（自我测试，修改代码，提交修改） |
30 |
22 |
| Reporting |
报告 |
30 |
35 |
| · Test Report |
· 测试报告 |
20 |
15 |
| · Size Measurement |
· 计算工作量 |
15 |
17 |
| · Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
30 |
23 |
| 合计 |
565 |
530 |
三：计算模块接口的设计与实现过程。
在设计之初，考虑到为降低代码单元的耦合度，我们将需求简单拆分为3个类，分别是输入，输出，和单词处理。使各个代码单元之间的耦合度尽量最低，不需要与其他代码纠缠不清。将类封装，数据以接口的形式传入。
在最初分析需求时，我们将代码分成4个类，分别是负责输入数据的input，输出需要数据的output，对需求处理的wordHandler，和统合的main。
input类含函数：FIleInput(); 用于提取文件中的单词信息。
output类含函数：_output(); 用于输出要求的计算结果数据。
wordHandler类含函数：get_chain_word(); 用于寻找最多单词数的最长链。
get_chain_char(); 用于寻找最多字母数的最长链。
这三个类每个类都是很独立的代码单元，三者间并没有什么关系，使得程序的耦合度很低。
UML图
四：代码复审过程
主要是检查代码规范和正确性，我们采取的方式是，我负责代码的规范检查，傅豪负责正确率的检验，最后互相验证。
参考文献，C#代码规划
https://jingyan.baidu.com/article/ed15cb1b0e3c0a1be36981e6.html
五：计算模块接口部分的性能改进。
六：计算模块部分单元测试展示。
主要是为了验证代码正确率和覆盖率，很重要的一步。
七：计算模块部分异常处理说明
我们有过的问题是文件的输入
- FINException：检测用户输入文件不合法时，抛出异常，main中捕获直接退出。
八：描述结对的过程
首先我们采用的程序语言是 C#，我们采用的平台是 Visual Studio 2017。 总体的合作方式是采用官僚式，即每个人都负责各自的一个功能，本次程序中一共有4个功能需要实现：字母占比、单词统计、词组统计、动词-介词统计，我负责字母占比、词组统计，舒曼莉负责单词统计、动词-介词统计。采用 git 来管理代码，每个功能个维护一个分支。主分支是一个程序并行流水线框架，定义了基本的API接口（实际上是一个基类），其他功能分支遵从主分支的基本框架，在这个基础上进行相应功能的开发测试，最后全部分支测试完毕后都合并到主分支中形成最终全功能版程序。
九：PSP表格记录下你在程序的各个模块上实际花费的时间
| PSP2.1 |
Personal Software Process Stages |
预估耗时（分钟） |
实际耗时（分钟） |
| Planning |
计划 |
120 |
95 |
| · Estimate |
· 估计这个任务需要多少时间 |
20 |
17 |
| Development |
开发 |
60 |
52 |
| · Analysis |
· 需求分析 (包括学习新技术) |
30 |
36 |
| · Design Spec |
· 生成设计文档 |
20 |
18 |
| · Design Review |
· 设计复审 (和同事审核设计文档) |
15 |
15 |
| · Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
15 |
15 |
| · Design |
· 具体设计 |
60 |
78 |
| · Coding |
· 具体编码 |
70 |
66 |
| · Code Review |
· 代码复审 |
30 |
26 |
| · Test |
· 测试（自我测试，修改代码，提交修改） |
30 |
22 |
| Reporting |
报告 |
30 |
35 |
| · Test Report |
· 测试报告 |
20 |
15 |
| · Size Measurement |
· 计算工作量 |
15 |
17 |
| · Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
30 |
23 |
| 合计 |
565 |
530 |
对结对作业的优缺点
-
- 能随时复审，能够及时发现逻辑错误
- 能在发现问题是互相交流拓宽思路
- 双方适时的交换角色能改变角度审视自己的逻辑和代码细节
- 缺点
- 在发现bug交流时容易打断个人的思路