| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
| Planning | 计划 | 120 | 90 |
| · Estimate | · 估计这个任务需要多少时间 | 20 | 20 |
| Development | 开发 | 120 | 125 |
| · Analysis | · 需求分析 (包括学习新技术) | 80 | 70 |
| · Design Spec | · 生成设计文档 | 60 | 65 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 70 | 78 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 20 | 15 |
| · Design | · 具体设计 | 100 | 70 |
| · Coding | · 具体编码 | 120 | 120 |
| · Code Review | · 代码复审 | 30 | 30 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 20 | 15 |
| Reporting | 报告 | 30 | 30 |
| · Test Report | · 测试报告 | 30 | 25 |
| · Size Measurement | · 计算工作量 | 20 | 20 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 15 | 15 |
| 合计 | 855 | 788 |
在文章的开头首先贴出本次GITHUB的地址:https://github.com/JackeyChANn/WordCount.git
一、关于解题思路与实现过程
在知晓了本次设计的程序大体需要什么后，再仔细研究其具体功能，发现其具体功能总体可以分为四个方面
1、统计字符数
关于解决这一功能所碰到的相关问题，本人感觉基本在已经掌握的知识范围内就可克服，于是上网稍加查询了相关资料便将这一功能基本解决（当然可能在一些细节方面仍有欠缺与不足）下面是解决这一功能所编程的函数截图
2、统计有效行数
实现这一功能其总体思路其实和第一个功能相差不多，主要还是找到文件路径读取文件然后再读取文档中的有效行数即可实现，下面是实现这一功能所编程的函数
3、统计有效单词数
实现这一功能大体思路还是一致的不过多了一个就是要做好间隔符的区分工作，因为间隔符是区别单词个数的重要评判标准，所以在实现这一功能上需要多做一个关于间隔符的工作，下面是实现这一功能所编程的函数
4、统计单词频数并输出频数前十的单词
这一功能的实现本人认为较为复杂，这其中不仅涉及到间隔符的处理还涉及到统计同行中的相同单词和不同行的相同单词，并且还涉及到统计不同大小写但是拼写一致的单词。为了解决这一功能，我在网上搜索了很多资料，在这过程中我也接触到了本人之前从未了解或是知道的一些知识，这其中比较典型的就是本人在查询资料以解决该功能时了解到的正则表达式，而这一功能实际上在确定该字符串是否为单词也用到了。下面是关于正则表达式的相关资料。
本人为解决这一功能查询了很多资料，也做过很多尝试，当然在尝试中自然也有很多失败。最后在很多已查询的资料的帮助并且自行综合下，以一种相对简单的方式最终大致实现了这一功能。下面是为了实现这一功能而编程的函数。
二、关于代码规范、互审以及这其中碰到的问题
关于代码规范的问题，由于这是第一次结对编程，以往都没有经验，所以在制定代码规范的这个问题上搜索了网上的很多资料，也借鉴了很多现在已有的规范，由于代码规范的篇幅较长，而本次项目总体上规模不大，不会用到我们搜到代码规范资料里面的所有条款，所以下面是一个关于我们确定的代码规范的大致的整理。
1. C# 代码风格要求（代码规范要求）
1.1注释
类型、属性、事件、方法、方法参数，根据需要添加注释。
如果类型、属性、事件、方法、方法参数的名称已经是自解释了，不需要加注释；否则需要添加注释。
当添加注释时，添加方式如下图所示：
1.2 类型（类、结构、委托、接口）、字段、属性、方法、事件的命名
优先考虑英文，如果英文没有合适的单词描述，可以使用拼音，使用中文是不符合要求的。
唯一可以使用中文的地方是枚举的枚举项，枚举项实际已经不属于本节标题的范畴了。这里只是放到一起说明，如下图所示：
1.3 不使用缩写
所有类型、方法、参数、变量的命名不得使用缩写，包括大家熟知的缩写，例如msg。
1.4 一个.cs源文件至多定义两个类型
如果两个类型的关系是紧密相关的，比如 产品、产品类型，此时Product类，和ProductType枚举可以定义在同一个Product.cs文件中。
但不能在一个.cs文件中出现两个不相关的类型定义，例如将 Product类和Reseller类（分销商）定义在一个BasicInfo.cs文件中。
1.5 类型名称和源文件名称必须一致
当类型命名为Product时，其源文件命名只能是Product.cs。
1.6 类型成员的排列顺序
类型成员的排列顺序自上而下依次为：
字段：私有字段、受保护字段
属性：私有属性、受保护属性、公有属性
事件：私有事件、受保护事件、公有事件
构造函数：参数数量最多的构造函数，参数数量中等的构造函数，参数数量最少的构造函数
方法：重载方法的排列顺序与构造函数相同，从参数数量最多往下至参数最少。
2、代码互审以及组合代码时碰到的问题
在确定了代码风格的基本要求之后本人与搭档就开始各自的代码编程工作，在这之前本人已经做过功能的细分，于是本人与搭档确定好功能工作的分配之后就开始着手实践，在这期间本人与搭档也保持关于代码的沟通与联系，但是在最后代码组合时却发现无法通过编译。在仔细审查整个已经组合的完成的代码和我们各自的模块代码之后发现的问题所在。这其中最主要的就是在进行同一个功能的时候我们的编程方式的不一样，例如文件的打开、读、写，以及其他方面之间的方式不一样或多或少地导致了编译无法通过。在发现问题所在之后，我们 迅速着手解决问题，将代码之中表达方式存在差异的地方迅速纠正，最后重新整编的代码成功通过编译并运行。
三、代码编译测试
关于代码进行测试展示之前的说明：
上面已经提到我将本次的程序功能分为了四个大块，所以在实现本次程序实现的功能的时候提供了一个选择， “1”对应的用户选择读取总行数。“2”对应用户选择读取总单词数。“3”对应用户选择读取总字符数。“4”对应用户选择输出单词频数和与之对应的单词。
1、当用户选择读取总行数
2、当用户选择读取总单词数
3、当用户选择读取总字符数时。
4、当用户选择输出单词频数和与之对应的单词时
五、写在最后的感想
本次结对编程是本人的第一次结对编程，所以在进行的过程中有很多不熟悉、不好做的地方，特别是本次程序要实现的所有功能其实有很多都是本人及搭档的知识盲区，所以需要做大量的资料搜索和汇总并且做好明确的分工，而且本次程序所有的功能以及要求新增添的功能要全部实现对于本人以及搭档来说难度较大所以在本次程序作业的完成上可能不是那么的完美。
但是本次结对编程确实也给了我很多新的体验和感受，让我初次感受到了以后工作将要面临的境况以及会碰到的困难并且让我知道了应该如何找寻一个合适的方向去克服这些出现在眼前的困难。
本次结对编程是本人与搭档的第一次配合，所以可能在效率感受上并没有感受出团队合作1+1>2的效果，因为本人以及搭档的编程水平均不高，在实际编程的过程中我们都会碰到很多自己难以解决的困难所以需要花费大量的时间和精力去解决这些我们在实际工作过程中碰到的问题，再加上沟通的成本以及本人与搭档在实现某些程序功能方面思路的不一致经常会争执所需花费的时间和精力，让本次作业的完成都稍显困难。但任何事有不好的一面也有其好的一面，虽然在本次结对编程的过程中，本人与搭档都碰到了诸多不利因素，但在解决这些不利因素和克服困难的过程中，本人与搭档常做沟通与交流，这让我们在实现某些具体的程序功能的时候有更多不同的思路碰撞从而以后在编程代码的时候有更多不同的选择，或许这些不同的选择可以让本人的代码效率变得更高或是更加无懈可击。
