第四周小組作業：WordCount優化

時間 2021-01-02

一、github項目地址：https://github.com/DouglasLee001/wordcountPRO

二、PSP表格

PSP2.1表格

PSP2.1	PSP階段	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	20	20
· Estimate	· 估計這個任務需要多少時間	5	5
Development	開發	30	30
· Analysis	· 需求分析 (包括學習新技術)	60	60
· Design Spec	· 生成設計文檔	40	40
· Design Review	· 設計複審 (和同事審覈設計文檔)	20	20
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	60	65
· Design	· 具體設計	30	30
· Coding	· 具體編碼	5	10
· Code Review	· 代碼複審	10	20
· Test	· 測試（自我測試，修改代碼，提交修改）	180	200
Reporting	報告	40	50
· Test Report	· 測試報告	40	50
· Size Measurement	· 計算工作量	20	20
· Postmortem & Process Improvement Plan	· 事後總結, 並提出過程改進計劃	10	10
	合計	580	605

三、模塊的接口實現說明

1）sort類：

重載comparator()函數，當兩個word對象的num值不同的時候，就返回兩者的num值比較結果，如果兩者的num值相同，就返回兩者的中string ::word的比較值

 1 class sort implements Comparator {
 2     public int compare(Object o1, Object o2) {
 3         word s1 = (word) o1;
 4         word s2 = (word) o2;
 5           if (s1.getNum() > s2.getNum())
 6            return -1;
 7           else if(s1.getNum()<s2.getNum())
 8          return 1;
 9           else {
10               if(s1.word.compareTo(s2.word)>0)
11                   return 1;
12               else 
13                   return -1;
14           }
15     }
16 }

　　2）類sortWord：提供將未排序的arrayList<word>數組變成已排序的,返回ArrayList<word>，調用重載了比較算符comparator的sort類

1 public class sortWord {
2     public ArrayList<word> Sortword(ArrayList<word> wordList) {
3          Collections.sort(wordList, new sort());
4          return wordList;
5     }
6 }

四、測試用例的設計

1）測試方法的考慮：

　　（1）對於我自身寫的兩個類，sort與sortWord類，前者是重載了comparator運算符，後者是進行排序，採用白盒測試方法，對不同的路徑進行覆蓋，需要對當不同的詞頻時，相同詞頻不同單詞，相同詞頻不同單詞長度的情況進行排序。

　　（2）對於組員所寫的輸入方法，進行黑盒測試，根據功能需求，需要考慮當輸入正常，輸入不爲txt文件，輸入文件不存在，輸入中只有一行空行時的情況進行測試。

　　（3）對於組員寫的單詞識別和詞頻統計方法，採用黑盒測試的方法，根據功能需求，考慮了邊界值條件，測試當內容爲空，內容爲帶「-」，常見字符，數字等情況，並進行了等價類劃分：

　　　　　　第一，Let’s，這種包含單引號的情況，視爲2個單詞，即let和s。

　　　　　　第二，night-，帶短橫線的單詞，視爲1個單詞，即night。

　　　　　　第三，「I，帶雙引號的單詞，視爲1個單詞，即i。

　　　　　　第四，TABLE1-2，帶數字的單詞，視爲1個單詞，即table。

　　　　　　第五，(see Box 3–2).8885d_c01_016，帶數字、常用字符和單詞的情況，視爲4個單詞，即see, box, d, c。

2）測試效率的考慮：使用junit框架能夠實現快速有效地進行鍼對性的測試，通過與自己的預期結構進行對比，查漏補缺。

3）測試用例表，具體測試代碼詳見github中的test文件夾

五.Junit測試截圖

（1）針對readfileBylines的測試，使用assertEquals進行判斷，並判斷了拋出異常時的情況。個人認爲達到了預期效果。

（2）對於sortword函數進行測試，針對num是否重複劃分了等價類，進行了白盒測試，由於代碼較爲簡單，測試用例設計了4個，個人認爲達到了預期效果

（3）對count函數的測試，由於採用了黑盒測試，因此需要針對不同等價類進行劃分，針對需求中的對於單詞的定義，設計如下各個等價類，並通過對代碼的分析，進行路徑覆蓋。設計了11個用例，達到了預期目標。

運行結果：

六，小組貢獻分：0.25

擴展功能：

一、代碼規範參照地址：http://www.cnblogs.com/xinz/archive/2011/11/20/2255971.html（鄒欣老師的博客）

1）選擇其中的「代碼風格規範」，包括了縮進，行寬，括號，斷行和空白的{}行，分行，命名，下劃線問題，大小寫問題，註釋。

2）個人認爲通過規範代碼可以增強代碼的可讀性和可調試性，方便進行團隊成員內部之間進行同行評審，命名規範可以使得各個變量一目瞭然，清晰地瞭解各個變量和類的作用，對於類，常用每個單獨的單詞首字母大寫，其餘小寫，而普通變量則第一個單詞首字母小寫，其後的單詞首字母大寫，比如讀文件的類ReadFileByLines,統計方法countWord。

二、對組員代碼的分析

分析了17034的代碼：（部分如下）

import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
import java.io.IOException;
import java.util.ArrayList;
public class readFileByLines {
    public String fileName;
    public readFileByLines(String theFilename){
        this.fileName=theFilename;
    }
    public ArrayList<String> fileString(){
        File file = new File(fileName);
        ArrayList<String>  lineArray = new ArrayList<String> ();
        BufferedReader reader =null;{
            try {
                reader = new BufferedReader(new FileReader(file));
                String tempString = null;
                
                while ((tempString = reader.readLine()) != null) {
                    lineArray.add(tempString);
                }
                reader.close();
            } catch (IOException e) {
                //e.printStackTrace();
                System.out.println("no file exits");
            } finally {
                if (reader != null) {
                    try {
                        reader.close();
                    } catch (IOException e1) {
                    }
                }
            }
        }
        return lineArray;
    }
}

優點：

　　1）符合命名規範，意義明確。

　　2）符合大小寫問題的規範，清晰明瞭。

缺點：1)缺少適當註釋

　　　2）括號沒有對齊

　　　3）大括號沒有每個佔一行，複雜的條件表達式中，邏輯優先級容易不清晰。

三、靜態代碼檢查工具選擇了：阿里巴巴Java開發代碼檢測IDE插件，參考安裝網址：https://www.cnblogs.com/ysgcs/p/7675977.html

四.

靜態代碼檢查過程

　　1）界面截圖：

2）代碼存在的問題都爲一些風格規範問題，對應的具體和解決方法分別是：

對於if/else語句應必須使用大括號，即使只有一行代碼

對於命名應該採用駝峯形式，對於sort應寫成Sort

五、整個小組代碼存在的問題

　　主要還是代碼風格不夠規範，註釋信息較少導致閱讀代碼時不方便，因爲一開始沒有這種習慣，導致後來手動添加比較麻煩；其次是命名規範不夠標準，其他常見問題與我自己的代碼相似，不在一一列舉。