一: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交流时容易打断个人的思路