《构建之法》第四次作业——结对编程
一、介绍
博客作业地址 | 课程链接 |
---|---|
Github地址 | 链接 |
同伴地址 | 链接 |
二、结对过程
我和结对的伙伴很熟悉彼此,认为能够很好的合作。
三、PSP表格
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 20 | 30 |
Estimate | 估计这个任务需要多少时间 | 800 | 800 |
Development | 开发 | 300 | 400 |
Analysis | 需求分析 (包括学习新技术) | 120 | 200 |
Design Spec | 生成设计文档 | 30 | 30 |
Design Review | 设计复审 (和同事审核设计文档) | 20 | 30 |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
Design | 具体设计 | 30 | 20 |
Coding | 具体编码 | 300 | 500 |
Code Review | 代码复审 | 30 | 60 |
Test | 测试(自我测试,修改代码,提交修改) | 100 | 20 |
Reporting | 报告 | 60 | 30 |
Test Report | 测试报告 | 30 | 30 |
Size Measurement | 计算工作量 | 20 | 20 |
Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
合计 | 1080 | 1410 |
四、解题思路
首先看到需要完成的任务时估计难度,步骤一二都是以前有了解过的东西,难度并不是很大,步骤三并没有尝试过所以去查找资料,步骤四的附加题感觉是难度最大的地方,和朋友商量之后决定看时间完成。
步骤一二就是简单的利用字符串函数或者匹配函数去实现,需要做一个单词判定。
步骤三采用的是switch去分配功能
五、设计实现过程
接口 | 功能 |
---|---|
asccounts | 统计字符总数 |
linescounts | 统计行数 |
wordcount | 统计单词总数 |
ynword | 单词判断 |
- 单元测试设计
六、代码互审
- 代码规范
- 变量命名由我们两个人预先编好
- 需要在接口上注释接口作用
- 互审
- 我看了朋友的代码后发现
- linescount里面的异常抛出不够严谨
- 第三步的新功能实现不够完善
- 我看了朋友的代码后发现
七、项目性能
在程序改进上,我在判断单词上首先使用的是一个一个的判断但后面发现使用正则匹配会更加快捷。
由图可以看出程序中占比最大的函数是countword
八、代码说明
第一步我们采用的就是简单的从文件读取 + 字符串函数 + 正则匹配
比如linescount:
string str = File.ReadAllText(@path.s);
int nr = Regex.Matches(str, @"\r").Count + 1;
第二步接口设计如上表
第三步新功能的增加我们是采用的switch分配
for (int i = 0; i < args.Length; i++)
{
switch (args[i])
{
//输出几个高频词
case "-m":
m = int.Parse(args[i + 1]);
break;
//输入文件路径
case "-i":
s = args[i + 1];
break;
//输出文件路径
case "-o":
outpath = args[i + 1];
break;
//输出n个单词的个数
case "-n":
n = int.Parse(args[i + 1]);
break;
}
}
- 部分功能展示
九、异常处理
比如在打开文件时 通过异常判断文件路径
try
{
string str = File.ReadAllText(@path.s);
num = Regex.Matches(str, @".").Count;
num = num + linescount.lines() - 1;
}
catch (Exception e)
{
Console.WriteLine("请输入正确的文件路径");
}
return num;
判定输出文件的路径
try
{
outpath = @"D:\xe.txt";
File.Exists(outpath);
}
catch (Exception e)
{
Console.WriteLine("无法找到改文件");
}