**倉庫位於： azure
可執行程式 (windows .exe) 位於：可執行檔案 （不是病毒）
首先我們採用的程式語言是 c++，我們採用的平台是 azure devops。 總體的合作方式是採用官僚式，即每個人都負責各自的乙個功能，本次程式中一共有4個功能需要實現：字母佔比、單詞統計、片語統計、動詞-介詞統計，我負責字母佔比、片語統計，舒曼莉負責單詞統計、動詞-介詞統計。採用 git 來管理**，每個功能個維護乙個分支。主分支是乙個程式並行流水線框架，定義了基本的api介面（實際上是乙個基類），其他功能分支遵從主分支的基本框架，在這個基礎上進行相應功能的開發測試，最後全部分支測試完畢後都合併到主分支中形成最終全功能版程式。
專案框架設計
框架的總體流程是我提出的，決定採用並行流水線的原因也是因為這個程式的邏輯存在著明顯的分離、並行空間。關於**的風格，我們採用的 google style guide，注釋規範從用的是 doxygen 注釋規範，整體的原始碼框架遵循c++開源工程專案的規範(包括src,include等檔案路徑)。
**框架設計
由於採用c++，而這些功能基本都圍繞著乙個中心主題：統計詞頻，所以我們採用的設計方式是：
首先我們基於的是並行流水線的框架，一共有三個執行緒，分別負責：讀取檔案(io), 文字分詞(計算), 統計(訪存)，兩個執行緒間採用生產者-消費者模型，所以一共有兩組生產者-消費者，其中文字分詞執行緒既擔任第乙個生產者-消費者模型中的消費者，又擔任第二個生產者-消費者中的生產者。所以這裡的乙個優化主要針對於對鎖的優化，我們希望執行緒持有鎖的時間能盡量的短，這樣並行的程度就能更大。所以乙個重要的優化是我們將所有設計到計算的任務都放置於鎖的外面，鎖內只負責讀取、存放相應的資料。
其次我們是對文字讀取的優化，原先的**在第乙個執行緒讀取檔案的乙個塊時會判斷是否都完整乙個單詞，即所讀的最後乙個位元組是否是字母或數字，如果可能不是乙個完整的單詞，我們需要再讀取一些字元來，直到是非字母且非數字的字元，才傳送讀取的塊。然而我們發現，io執行緒往往是整個程式的執行瓶頸，所以我們將判斷是否為完整單詞的這一部分放到文字分詞的位置，即在這個執行緒中，我們維護乙個緩衝區，如果發現最後乙個獲得的位元組是字母或數字，那麼我們只會先處理之前的單詞，留下最後乙個等待下一次的讀入進行合併。這樣我們程式的執行速度能比原來提高25%（粗略）。
其他還有些細節的優化，如一次讀取塊的大小，我們往往會取系統頁大小的整數倍（即4k的倍數），防止出現低效的頁置換。
可優化的部分
事實上這個程式還有很多可以優化的部分，有乙個最重要的點是更細粒度的並行，這可以通過兩點做到：第乙個是使用更多的執行緒，維護乙個優先隊列表，這樣可以不需要等到全部都統計完成後再進行排序，可以邊統計邊排序；同時還可以使用openmp多執行緒庫，來做到比如分詞、排序的並行。
由於時間上的限制，我們並沒有在這方面展開更多的優化。
我的結對程式設計同伴是舒曼莉。
她的優點：
她的缺點：
我們採用的效能分析工具為visual studio performance profiler
我們主要統計的是熱點函式，針對熱點函式做優化來下降整體的執行時間。
下圖是我們獲得各個函式的執**況表（在統計片語的情況下），從牆上函式內執行時間(elapsed exclusive time) 來看，第乙個熱點函式是正則匹配中使用到的，說明正則匹配在整個過程中擁有著較大的開銷。同時第三大開銷是std::getline(), 這是存在於檔案讀取的，由於檔案大小已經固定，讀取的時間基本也就不會再變。但是可以整體減少整個執行緒的執行時間，於是也就有了上述的優化。
實際上，更適合我們做效能分析的是效能分析工具的concurrency 模組，這個模組應該可以看到各個執行緒的負載情況，從而對執行緒間能做到更好的負載均衡。但是因為windows許可權問題，這個模組的工具無法使用，因此無法做出更進一步的效能分析。
我們測試了傲慢與偏見下片語為3的情況，
測試命令為(powershell)
measure-command測試時間穩定在 0.13秒左右。
結對程式設計可以提高**編寫的速度，同時這次程式設計採用的框架也是一般大型開源工程採用的原始碼框架，所以對專案程式設計有很大的收穫。
結對程式設計 詞頻統計
搭檔 施蓓蓓 原始碼 github 貢獻比例 50 結對程式設計 1 要求 基於作業3的結果，讀取乙個較小的文字檔案a tale of two cities.txt，統計該檔案中的單詞的頻率,並將統計結果輸出到當前目錄下的 result1.txt 檔案 2 程式 ifstream infile a ...
結對 詞頻統計
結對程式設計 pathner 濮成林 部落格 1.詞頻統計 環境依賴 對濮成林詞頻統計進行需求的再討論 確定輸入 txt格式純英文文件大小不超過10m 分析結果排序 按順序輸出前n個 1.上傳文件 2.統計所有單詞數目 暫時將複數形式認定為單獨詞 縮寫形式暫不支援 3.統計文件的總行數。4.統計文件...
現代軟體工程 結對程式設計 詞頻統計
這次的任務是對文字檔案的詞頻統計，要求在這裡 詞頻統計作業要求 雖然要求的細節一改再改，我們終於還是如期完成了這個專案，並且因為此次結對程式設計的主題任務是效能分析，我們還做了效能分析和一些優化。不同於要求，我們的幾次commit除了實現功能外，大多是因為要求的變化而對 進行修改，或是修復bug 優...