1、Fork倉庫的Github項目地址：

https://github.com/linlkg/PairProject2018

2、預估各個模塊開發耗費的時間：

3、計算模塊接口的設計與實現過程：

-第一步：相關類設計

• 讀取輸入輸出文件類IOfile用於定義用戶輸入/輸出的文件名和路徑；
• 單詞類Word用於存儲單詞提取以及單詞詞頻統計；
• 詞組類Phrase用於存儲詞組提取以及詞組頻度；
• 接口類UserInterface用於存儲用戶輸入的參數值；

• 相關類圖如下：
  

• 第二步：相關操作函數
  • 提取單詞函數getWord()用於根據分隔符將文件流中的單詞提取出來並存儲；
  • 統計單詞頻率函數countWord()；
  • 排序輸出單詞頻度函數sortWordOutput()；
  • 提取指定長度詞組getPhrase()；
  • 統計詞組頻率函數countPhrase()；
  • 排序輸出詞組頻度函數sortPhraseOutput()；

4、計算模塊接口部分性能改進

-性能分析圖（由VS 2017/JProfiler的性能分析工具自動生成）

5、計算模塊部分測試結果

輸入文件為群裏分享的測試文件bible-kjv.txt

6、計算模塊部分異常處理說明

讀文件時若讀取文件失敗則拋異常
//讀入用戶寫好的TXT文件，
//嘗試讀取文件，若失敗catch到異常並打印出來

try {
File file = new File(args[0]);
Scanner input = new Scanner(file);
String path = input.next();
List<String> wordArray = new ArrayList<String>();
int countChar=0;
int countWord=0;
int counLine=0;
InputStreamReader reader = new InputStreamReader(new FileInputStream(args[0])); // 建立一個輸入流對象reader
BufferedReader br = new BufferedReader(reader); // 建立一個對象，它把文件內容轉成計算機能讀懂的語言
}catch (Exception e){
e.printStackTrace();
}

7、關鍵代碼分析

//統計行數
一行一行讀入文件，所以每行讀入次數加一，但要註意去除空白行
再將分割好的單詞與正則表達式匹配以便統計詞頻

//單詞的詞頻統計
如果已有相同的單詞，則詞頻加1
否則創建一個<key,value>以保存新的單詞

//按value的大小進行排序並輸出詞頻最高的前十個
按字典序大小進行排序，當結果少於10個時全部輸出，當結果多於10個時輸出前10個結果

8、描述結對的過程

結對體會：

• 結對中汪璟玢充當領航員（Navigator）角色，林靜充當駕駛員（Driver）角色。先是一起討論做了大體類的設計和算法流程設計，接著林靜就開始編程。兩個人編程還是比一個人來的效率高些，有問題一起討論，錯誤也第一時間被指出，特別是一開始的討論，就先定義和封裝了幾個要用到的函數，避免了後期推翻修改，提高了開發效率。不過缺點也是有的，就是一個人在編程的時候，另一個人不好打擾，默默滴看，後面發現沒有完全按照領航員的設計來實現。函數沒有完全按照預期抽象出來，導致效能分析處有問題！設計當中的接口和新增功能未實現，但類圖當中的設計將其抽象出來方便了後續的代碼優化。
• 這次的體會真的很深，實打實的結對，兩人分工合作完成一個看似不難的任務，實際執行過程中還是遇到不少困難，結對的最大好處就在此處體現：在遇到困難的時候總是可以通過提醒和討論解決之！
• 兩個人的合作總是勝過一個人埋頭苦寫代碼的，通過兩個人結對的交流和探討，會比平常一個人設計節約了不少的時間。由於生疏在百度許多東西的寫法上耽

結對編程-詞頻統計（第9組）