1、Fork倉庫的Github項目位址：
https://github.com/linlkg/PairProject2018
2、預估各個子產品開發耗費的時間：
| PSP2.1 | PersonalSoftware Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 20 | |
| -Estimate | -估計這個任務需要多少時間 | ||
| Development | 開發 | 230 | 303 |
| -Analysis | -需求分析（包括學習新技術） | 25 | |
| -Design Spec | -生成設計文檔 | ||
| -Design Review | -設計複審（和同僚稽核設計文檔） | 5 | 8 |
| -Coding Standard | -代碼規範（為目前的開發制定合适的規範） | 10 | |
| -Design | -具體設計 | ||
| -Coding | -具體編碼 | 120 | 150 |
| -Test | -測試（自我測試，修改代碼，送出修改） | 30 | 60 |
| Reporting | 報告 | 80 | 105 |
| -Test Report | -測試報告 | ||
| -Size Measurement | -計算工作量 | 35 | |
| -Postmortem&Process Improvement Plan | -事後分析，并提出過程改進計劃 | 50 | |
| - | 合計 | 330 | 428 |
3、計算子產品接口的設計與實作過程：
-第一步：相關類設計
- 讀取輸入輸出檔案類IOfile用于定義使用者輸入/輸出的檔案名和路徑；
- 單詞類Word用于存儲單詞提取以及單詞詞頻統計；
- 詞組類Phrase用于存儲詞組提取以及詞組頻度；
- 接口類UserInterface用于存儲使用者輸入的參數值；
- 相關類圖如下：
結對程式設計-第9小組 - 第二步：相關操作函數
- 提取單詞函數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）角色。先是一起讨論做了大體類的設計和算法流程設計，接着林靜就開始程式設計。兩個人程式設計還是比一個人來的效率高些，有問題一起讨論，錯誤也第一時間被指出，特别是一開始的讨論，就先定義和封裝了幾個要用到的函數，避免了後期推翻修改，提高了開發效率。不過缺點也是有的，就是一個人在程式設計的時候，另一個人不好打擾，默默滴看，後面發現沒有完全按照領航員的設計來實作。函數沒有完全按照預期抽象出來，導緻效能分析處有問題！設計當中的接口和新增功能未實作，但類圖當中的設計将其抽象出來友善了後續的代碼優化。
- 這次的體會真的很深，實打實的結對，兩人分工合作完成一個看似不難的任務，實際執行過程中還是遇到不少困難，結對的最大好處就在此處展現：在遇到困難的時候總是可以通過提醒和讨論解決之！
- 兩個人的合作總是勝過一個人埋頭苦寫代碼的，通過兩個人結對的交流和探讨，會比平常一個人設計節約了不少的時間。由于生疏在百度許多東西的寫法上耽誤了不少時間，導緻進度有些被拖慢。領航員在這個過程中一直提醒着注意要點，把控整個程式的品質。但林靜自我反思在這次結對當中存在的許多不足，程式設計能力的不足導緻沒有很好地實作“領航員”設計出來的實作方案，望以後更加努力，才能更好地結對程式設計出理想的作品！