程式設計作業要求：要求

github地址：github

2. PSP表格(單位:h)

3. 一開始的需求只是對於不同引數做不同處理和僅有的引數組合，所以我們採用的方式是對於每一種引數寫一個函式。後來需求變更為引數組合，有必選和可選引數，就更改了介面設計。為實現Information Hiding，採用成員私有並用公有方法訪問的方式。為實現Loose Coupling，將不同引數以獨立函式實現並用bool量控制可選引數，防止需要在不同功能中多次實現可選功能。介面設計為用-d -s處理出待處理字串，對-c -f -p -q單獨實現四個函式，接受相同的輸入（待處理字串），得到相同的輸出（頻率表），之後根據-n對統一的輸出進行處理。

4. 兩個類，一個argparse類用於分析命令列以後打包每個引數及其值。另一個Freq類用於記錄字母頻率和穩定排序。演算法中最關鍵的部分應該是PhraseCount中匹配每個單詞的部分。由於正則庫函式實現太慢，所以自己實現了特殊化的正則匹配，為了把邏輯寫對畫出狀態機。

5. UML

6.  (結對程式設計照片暫無)我們採用的結對過程為為一人主要負責程式編碼，另一人主要負責程式碼複審和單元測試編寫。至於優缺點，我覺得我對C++的庫和新特性比較熟悉，對bug的處理比較熟悉，對效能分析工具比較熟悉。缺點是編碼速度不夠快。對於parterner，我覺得優點在於能很敏銳的發現我程式設計中的隱藏bug，編碼能力挺強，擅長編寫單元測試，對新工具的學習和熟悉能力很強，很有耐心也挺可愛的。缺點是寫C++的時候容易寫成python的語法<_<?

7. 我們採取的分析工具是VS Performance Inspector. 對熱點函式進行優化。比如發現庫函式isalpha和isalnum的魯棒性很差（會接受亂碼字元即非ascii字元的輸入而造成崩潰），效能也不夠，就自己內聯實現了一個。發現正則庫查詢速度太慢，就自己寫了一個專門的函式進行匹配。但是有些庫函式的效能還是挺高的，比如boost::algorithm::join, 我們用這個將vector中的string聯成一個phrase。還對一些資料結構進行了優化減小複雜度，比如採用基於桶的資料結構進行查詢和統計操作。

8. 我們採取的單元測試編寫工具是VS自帶的單元測試。然後對於每個push的版本作一次迴歸測試。我們可能沒有做到單元測試程式碼覆蓋率100%，但是和助教給的示例程式的輸出可以對任何引數保持輸出一致。

9. 我們最後的效能是對於105M的檔案，在沒有-v選項時PhraseCount的時間為5s左右（包括1.5s檔案讀入時間）,有-v選項時時間為9s。對pride-and-prejudice.txt沒-v大概0.00091s,有-v0.11s左右。