与大佬的第二次结对编程
这次的任务是对文本文件的词频统计，要求在这里：词频统计作业要求
虽然要求的细节一改再改，我们终于还是如期完成了这个项目，并且因为此次结对编程的主题任务是效能分析，我们还做了效能分析和一些优化。
项目地址：Word Count
不同于要求，我们的几次commit除了实现功能外，大多是因为要求的变化而对代码进行修改，或是修复bug、优化性能。
合作
在项目开始之前选择语言的阶段，我们商讨的结果是，由于我们都没有用过python平台的效能分析工具，并且刚好我比较熟悉C#的文本处理，所以决定这次我们的编程语言选择C#，合作方式是由我来做驾驶员，队友做领航员。
design guideline：由于此次编程任务的功能比较直接但是繁琐，我们一开始就达成一致从最简单的功能开始写起，并列地完成每一个功能，再做优化。
coding convention：由于我们的合作方式，我们的coding convention基本按照我的习惯和VS的自动缩进等来，命名等则是我们一边写一边达成一致。
reach agreement： 在合作过程中，但我们有了不一致我们会停下工作来讨论，直到reach agreement
此次项目的目标是优化程序运行的速度，功能实现本来不难，而时间很长，于是我们想要先把功能实现然后进行测试和优化。于是一开始我们连续几天晚上一起结对编程，大体实现了功能，然而由于我们的理解与具体的要求有偏差，并且要求本身也没有非常确定，我们的功能实现并不能作为最终版本，因此我们搁置了一个多星期。当任务要求的细节终于大概确定我们终于可以继续工作时，由于我个人的原因，我们实际可以工作的时间只有两个工作日的晚上和一个周六的白天。为了完成任务，我们只好推迟了休息时间，加班加点地实现功能并做了一些测试和优化。
队友
我的队友的优点：想算法的时候逻辑清晰，对代码的规范意识比较好，忍受了我有限的时间陪我熬夜赶ddl
缺点：在做领航员的实时复审工作时会漏掉一些bug，有点不够细心
性能优化
我们使用VS的performance profiler做效能分析，并根据report的热行等信息做优化。
在具体的操作过程中，我们发现C#的List<T>数据结构的一些方法，如List<T>.Contains(), List<T>.Count()，内部是用遍历的方式来实现，性能非常差。针对前一个问题我们写了一个VocabTree类，试图用递归的方法索引单词，效果有很大改善，后来我们使用了HashSet和Dictionary来替代VocabTree，速度更快。而后一个问题我们换了List<T>.Length就解决了。List<T>.Sort()方法耗费的时间也很长，于是我们将改为使用IEnumerable<TSource>.OrderBy()，效果明显提升。
这之后，我们发现在输出统计结果的时候，C#的Console.WriteLine()耗时超过了50%，于是我们优化了逻辑，将原本一次write一个字典项改为将字典项存进buffer再write。这样性能也提升了不少。
然后我们分析，如果想要继续优化，需要修改代码逻辑、使用多线程，但由于时间和精力十分有限，我们没有再继续做下去。