第三次作业-张鑫

 

一：Fork仓库的Github项目地址

 https://github.com/Jupi4ter/WordCount.git

 

二：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

 

三：计算模块接口的设计与实现过程。

在设计之初，考虑到为降低代码单元的耦合度，我们将需求简单拆分为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接口（实际上是一个基类），其他功能分支遵从主分支的基本框架，在这个基础上进行相应功能的开发测试，最后全部分支测试完毕后都合并到主分支中形成最终全功能版程序。

 

能随时复审，能够及时发现逻辑错误对结对作业的优缺点

• • 能在发现问题是互相交流拓宽思路
  • 双方适时的交换角色能改变角度审视自己的逻辑和代码细节
• 缺点
  • 在发现bug交流时容易打断个人的思路

 本人将完整代码粘贴到了ubuntu  https://paste.ubuntu.com/p/4CwYCV4wvJ/

 

在此结对编程的过程中，主要负责的版块是代码的设计测试和最后的总结，也就是文章中提到的三，四，五，六过程。因为有ACM算法的基础，所以比较擅长代码算法的设计和修改测试。

 加上队友负责的其他版块，很好的一起完成了这个项目，受益匪浅。

 

 

转载于:https://www.cnblogs.com/Czay/p/10658587.html