一、 1、
2、
二、结对过程
1、在拿到本次作业后，本人对于这个项目并没有什么思路。并且对于结对编程这种新方法也是第一次了解，所以在网上查询资料后，本人就主动向同学发出了邀请。在结对完成后我们也很快对各自的任务进行了分派。虽然每个人的任务不大相同，但我们在完成各自的任务时并不是各自埋头苦干。当遇到难题时，我们常常一起讨论解决。我们希望能运用一个team的力量。发挥出1+1>2的功效。非摆拍照片如下:
2、psp表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
| Planning | 计划 | 20 | 25 |
| · Estimate | · 估计这个任务需要多少时间 | 20 | 25 |
| Development | 开发 | 870 | 880 |
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 50 |
| · Design Spec | · 生成设计文档 | 20 | 30 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 10 | 30 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 30 | 30 |
| · Design | · 具体设计 | 100 | 90 |
| · Coding | · 具体编码 | 500 | 450 |
| · Code Review | · 代码复审 | 100 | 120 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 50 | 60 |
| Reporting | 报告 | 80 | 110 |
| · Test Report | · 测试报告 | 30 | 40 |
| · Size Measurement | · 计算工作量 | 20 | 20 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 50 |
| 合计 | 970 | 1060 |
三、解题思路
本人在一开始拿到这个项目时脑中没有一个能够清晰解题的轮廓，于是本人开始着手在各个网站查找资料。在看了一些各个模块的解决方案后，本人开始抓住了一些脉络和模块之间的连接。在分工后，本人对于各个模块的任务也了解的比较充分了。由于作业要求各个模块能够独立出来，所以我们将不同的功能模块分别写在不同的类里面。在每个类里将复杂问题渐渐简单化。从函数内部一步一步向外部拓展。最后达到输出的要求。又在需要调用的主函数里进行调用。
四、设计实现过程
本次项目代码设计有三个类totalchar、 totallines、 totalwords分别实现三个不同的功能，在每个类里都有一个各自的统计函数和打印函数。在totalwords里多了一个使用正则表达式来判断英文单词的函数IsLetter。而运行过程也非常简单易懂，首先文件名由主函数输入，再传递到每个类里的打印函数里，并调用各个功能函数进行统计返回结果。在我看来，这样做有一个优点就是各个块非常明确，也很容易确定有错误的地方。在审查时可以一步一步的检查到每个函数是否正确完成任务。所以基本流程如下：输入文件名>>构造新类调用打印函数传递文件名>>读取文件>>调用统计函数返回结果。由于函数个数较少，所以在实现过程中，统计函数非常重要，所以在编码过程中，我先就准备完成统计函数，将统计函数的功能完备齐全再进行项目的其他部分。所以在我的解决方案中统计函数是关键的代码。不论是打印函数还是判断函数都需要以统计函数为中心来建立。
五、<1>简易C#代码规范
1、 类型（类、结构、委托、接口）、字段、属性、方法、事件的命名
优先考虑使用英文（尽量使用英文），如果实在没有合适的英文进行描述，可以使用拼音，使用中文是不符合要求的。
2、不使用缩写
所有类型、字段、属性、方法、事件尽量不使用缩写，包括大家熟知的缩写，例如msg。
3、不使用单个字母的变量
不使用单个字母的变量, 像 i、m、n，使用index等来替换，用于循环迭代的变量除外。
4、 注释
类型、属性、事件、方法、方法参数，根据需要添加注释。如果类型、属性、事件、方法、方法参数的名称已经是自解释了，不需要加注释；否则需要添加注释。
5、类型名称和源文件名称一致
6、不在代码中使用具体的路径和驱动器名。 使用相对路径，并使路径可复用
7、一个方法只完成一个任务。不要把多个任务组合到一个方法中，即使那些任务非常小
8、如果if语句块的内容只有一行，可以不加花括号，并且最好和if语句位于同一行
9、返回bool类型的方法、属性的命名
如果方法返回的类型是bool类型，则其前缀为Is，例如：IsHidden。
如果某个属性的类型为bool类型，则其前缀为Can，例如：CanHidden。
10、不要“捕捉了异常却什么也不做“。如果隐藏了一个异常，你将永远不知道异常到底发生了没有
<2>代码复审
虽然本人和pattern早早就制定好了我们的代码规范，但是由于在之前并没有规范自己。所以在日常编码中我们还是很轻易就被自己曾经的一些个人习惯带走，这导致我们在代码复审的时候发现出现了很多我们之前定制好的规则被我们打破的情况。比如在给函数和类命名时，我们只能将自己熟悉的函数名规范正确，但在进行函数构造的时候我们往往只能用拼音首字母来命名，这就造成了虽然自己非常了解代码意思但队友并不了解的情况。再加上在每个类和函数里注释不清晰和分段不明显我们在看对方的代码时必须不断的询问和修改，这花费了我们不少时间。
六、性能分析
在进行程序性能改进上，我主要着重在将函数简化这块上，在写代码时并没有注意到一些没有必要的定义。而且在本可以一两行代码解决的问题自己却用了一些非常复杂的方法，但是在和自己的pattern进行代码互审时，自己的知识盲区就能被对方发现并互相解决。
七、展示代码
本人在代码中主要写了这三个功能，统计非汉字字符、统计单词总数和文本行数。由于作业要求各个模块能够独立出来，所以这三个功能我分别写在三个类里面，在主函数里进行分别调用。并向三个不同功能的类里的打印函数进行传递地址。每个类里的统计函数均返回要统计的项目结果，最后打印。
八、单元测试
在单元测试中，我选择了比较容易出错的汉字来进行测试，以防在统计字符时将汉字也统计进去。但是在测试中给出期望值时我还是遇到了不小麻烦，由于自己对字符不是很了解，虽然在测试文本中给了很多容易出错的字符串但是自己也不能数清楚。尤其在统计字符时，自己对换行符作两个字符算不清楚，导致多次测试都失败。最后不得不将文本减少为两行从才意识到自己的错误。
九、作业感受
在经过解决此次项目的实践过程后，本人最大的收获就是理解到了一个优秀的团队的重要性。在分派完任务后，那就必须互相信任。在分别编码时，两人需要有足够的交流时间用以来了解对方的想法。在此次项目中，本人与队友分工合作，虽然在最初的时候有意见并不统一的时候，但是在两人不断的磨合和交流后，我们越来越来有团队的感觉，尤其是在后期的时候我们的思路不谋而和。这让我意识到，一个团队的大方向必须一致的重要性。或许两人在一个项目都有自己独立的看法，但毫无疑问，在一个项目中择优是必要的，也肯定是最好的。所以在最初的时候我与我的队友肯定是没有发挥出1+1>2的能力的，但随着后期我们的不断努力和互相促进。我有理由相信我们肯定是发挥出了大于两个人的团队作用的。最后就是在此次项目中我感受到的关于我自己的粗心问题，平常自己编码时候，粗心导致的问题可能自己遇到就自己解决了。但是经过这次结对编程后，我明白粗心导致的问题绝对是不容小觑的。因为这会给整个团队带来致命的问题。不仅让自己受损，更头疼的是让自己的队友也白白浪费时间和精力。所以我必须在以后的编程中重视这个问题。