作業要求及Github連結

作業要求：文字檔案中英語單詞的頻率
專案原始碼：統計詞頻

合作方式

有了第一次結對程式設計的經驗，我們這次有意識的採取了多種合作方式：

• 結對程式設計，我和隊友共用一臺顯示器和電腦完成了最簡單的-c -f標籤的處理和輸入輸出統一。
• 各自獨立程式設計，我和隊友各自獨立完成了-v，-p，-d，-s標籤的處理
• 遠端程式設計，我和隊友通過語音的方式共同進行效能優化。
  合作中有以下感觸令我印象深刻：

1. 在程式的開始階段兩個人結對程式設計能讓兩個人都對程式有很深刻的瞭解，尤其是函式的介面設定，要比簡單在紙上寫一下然後分頭獨立編深刻的多。
2. 在搭完底層框架後可以考慮各自獨立程式設計，好處是效率高，缺點是一旦分開程式設計後，就很難再對隊友的程式有很多瞭解了，但鑑於軟體工程總歸不可能一個人瞭解所有程式碼，各自獨立程式設計不失為一個趕進度的好方法。
3. 在效能優化是很需要兩個人的討論的，我們兩個都是第一次做優化，有一種慢工出細活的感覺，兩個人討論能想到很多細節。

程式碼風格討論

我們兩個人用python都比較多，而且在結對程式設計階段，我們的程式碼風格很自然就統一了，接下來各自獨立程式設計的時候，程式碼風格就一直一致的延續下來了。

時間分配

由於此次作業時間內我要回合肥做4天的物理實驗，所以作業的時間比較趕，優化的時候沒有做多執行緒的優化，只是在流水線的基礎上做了簡單優化，也沒有改變儲存的資料結構。

評價隊友

優點：

• 程式設計能力強，編得快
• 熟練使用vs和pycharm的效能分析工具
• 對程式設計有熱情，勤奮

缺點：
對python的基本資料型別操作不是很熟練

程式碼優化

由於作業的後幾天我們都在合肥或在出差，所以先趕出來了一個初始的版本，然後把各種功能加上去之後一測，要兩秒多：

然後優化了以下幾點：

• 在第一個版本的程式碼裡我們是用一個函式判斷一個字元是不是一個小寫字母，結果這個函式被呼叫了百萬次，很費時間，我們把判斷字元是否屬於小寫字母（或大寫字母、數字、空格）優化成了set的in判斷運算。
• 在第一個版本中我們不論原始字元的大小寫是什麼，把它統一轉化成小寫，優化成了只有大寫字母才轉化。
• 由於大多數情況下我們遇到的都是小寫字母，我們在獲取單詞的函式中優化了if-else條件判斷的順序。
• 優化了一些小細節，比如list.append(item)沒有list+[item]快
• 對於組合邏輯，如-v，-p，我們可以只掃描一遍txt檔案，而不是掃描兩遍，先處理-v，再處理-p。

優化完的時間為：

還是不是很快，但繼續優化可能要用更深刻的優化方法，我們就沒有再嘗試了。
優化過程能很明顯的感覺到，隨著速度的提升，程式碼可讀性和冗餘都在增加。

上述優化我們是從底層一步一步優化的，比如-v是要用-f的功能的，我們只貼了最後一步的圖。

對於單元測試，我們是在2.5s版本的基礎上優化，每優化一步測試一下，保證輸出是一樣的。截圖都是一樣的結果，我就沒有貼上去。
時間測試和程式碼覆蓋率測試我們是用的pycharm的圖形使用者介面，沒有調包。