基本功能

1、github地址

https://github.com/SSS-SY/wordcount-pro

2、PSP表格

3、接口實現

在討論過後，我們將任務劃分為四個模塊，具體模塊和分工如下：

1. 詞頻統計

功能描述：統計各個單詞的出現次數

接口描述：輸入一個字符串，輸出一個map結構

負責該模塊的小組成員：庹舒月

2. 詞頻排序

功能描述：將統計結果進行排序

接口描述：輸入一個map結構，輸出一個vector結構

負責該模塊的小組成員：俞亮

3. 輸出模塊、構造和析構函數、文件長度函數

功能描述：

(1). 輸出模塊：輸出結果到result.txt文件

(2). 構造和析構函數：類的構造和析構函數

(3). 文件長度函數：獲取輸入文件長度

接口描述：

(1). 輸出模塊：輸入一個vector結構，輸出一個result.txt文件

(2). 構造和析構函數: 無

(3). 文件長度函數：輸出文件長度

負責該模塊的小組成員：辜之皓

4. 輸入模塊、主函數和架構設計

功能描述：

(1). 輸入模塊：讀取文本為一個字符串對象

(2). 主函數：調用其他小組成員的接口，是主要邏輯

接口描述：

(1). 輸入模塊：輸出一個字符串對象

(2). 主函數： 無

負責該模塊的小組成員：唐明華

實現描述

負責將統計結果輸出到指定文件，構造和析構函數，文件長度函數。

輸出模塊十分簡單，一個循環直接把數據輸出到文件就行了：

void output_result(const WC::WordSet& ws) {
  ofstream fout("result.txt");
  for (int i = 0; i < ws.size() && i < 100; i++) {
    fout << (ws[i]).first << ‘\t‘ << (ws[i]).second << endl;
  }
}

構造和析構函數、文件長度部分的工作主要是初始化整個類，打開輸入文件，設置文件長度，關閉文件等：

explicit WC(const char* filename)
    : _fp(std::fopen(filename, "r")), _pool(10) {}

~WC() { std::fclose(_fp); }
int file_length() {
  fseek(_fp, 0, SEEK_SET);
  fseek(_fp, 0, SEEK_END);
  int ret = ftell(_fp);
  fseek(_fp, 0, SEEK_SET);

  return ret;
}

三.測試用例

使用了google test框架進行測試

設計了三個測試用例來測試文件長度是否能夠正常獲取，以及輸入錯誤文件時是否能夠正常處理

設計了十一個測試用例測試詞頻計數部分，覆蓋了特殊字符，多個-字符等等各種情況

設計了六個測試用例測試詞頻排序部分，測試了大小寫，單詞長度等等各種情況

測試用例列表如圖所示：

運行單元測試，如圖所示：

四. 小組貢獻

經過討論，各個小組成員根據自己的參與情況、代碼質量和代碼量得出了如下評分：

庹舒月: 0.28

辜之皓: 0.26

唐明華: 0.23

俞亮: 0.23

擴展任務

一.代碼規範

因為我們選擇了C++語言進行開發，所以參考了google style guide

我對其中關於類的標準進行了了仔細閱讀，了解了“不要在構造函數中調用虛函數, 也不要在無法報出錯誤時進行可能失敗的初始化”，”不要定義隱式類型轉換. 對於轉換運算符和單參數構造函數, 請使用 explicit 關鍵字“等等規則

這讓我對C++類的編寫有了新的認識

二.選擇靜態測試工具

使用了google官方提供的cpplint工具進行測試

下載鏈接：https://github.com/cpplint/cpplint

三.同行評審

經過一定的討論，我們決定唐明華和庹舒月之間進行代碼互評，辜之皓和俞亮之間進行代碼互評

因為我們都使用了一些代碼格式化的工具，所以在代碼風格方面十分統一

我對俞亮的代碼進行了閱讀，在設計方面，有少量冗余代碼，總體來說沒有重大問題

俞亮對我的代碼進行了評審之後，指出我在叠代器使用方面的問題，我對此進行了修改

使用cpplint工具的輸出結果如圖所示：

重新運行了單元測試輸出結果如圖所示：

四.問題總結和反思

叠代器循環的條件判斷應使用!=符號，而不是<=符號

在其他方面上，我了解到了代碼格式化工具的方便性和重要性，以及閱讀goole style guide讓我對C++代碼規範有了新的認識

高級任務

一.測試數據

我們找了莎士比亞全集的英文版txt文檔，有5Mb大小

使用這個數據，我們測試後發現大致需要3秒的時間才能處理完整個文件，運行截圖如下：

二.組內評審

針對可能影響程序性能（制約因素），我們小組進行了組內評審，討論。

主持：

庹舒月

評審：

唐明華、辜之皓、俞亮

評審主題：

1.影響程序性能的主要因素

2.有何建議

討論結果：

我們討論之後認為，主要的性能瓶頸在於需要讀取整個文件之後再開始統計，因為磁盤讀寫的速度非常慢，導致了整個程序運行效率低

解決方案：

使用多線程，一邊讀取數據，一邊開始統計讀取部分的數據，之後再將各個部分的統計結果合並，可以大大提高性能

三.修改之後的結果

修改之後程序性能有了成倍的提高，運行時間大概在0.7秒左右，提高了大約4倍的性能

運行截圖如下：

四.心得體會

經過這次作業，我深深地感受到軟件開發、軟件測試、軟件質量三個過程是密不可分、息息相關的

6、參考鏈接

1. goole style guide：

https://github.com/google/styleguide/

軟測第四周作業 wordcount 優化