與大佬的第二次結對程式設計

這次的任務是對文字檔案的詞頻統計，要求在這裡：詞頻統計作業要求

雖然要求的細節一改再改，我們終於還是如期完成了這個專案，並且因為此次結對程式設計的主題任務是效能分析，我們還做了效能分析和一些優化。

專案地址：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。這樣效能也提升了不少。

然後我們分析，如果想要繼續優化，需要修改程式碼邏輯、使用多執行緒，但由於時間和精力十分有限，我們沒有再繼續做下去。