• 1.基本任務

• 項目地址

　　https://github.com/JarrySmith/WordCountPro

• PSP表格

• PSP2.1表格

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

• 接口實現

　　我做的工作是：

　　1.整理任務需求，然後按照需求劃分所需要的模塊

　　2.並規定要模塊與模塊之間的接口，提供各個模塊實現的大致思路，所需用到的變量類型，方法等等

　　具體可以參見 項目框架與分工文件 該文件是由我獨立完成的

我們這次總共劃分了三個模塊：

　　1.輸入處理模塊 主要負責對輸入進行有效性校驗，識別和處理無效輸入，並從中提取所需數據

　　2.核心處理模塊 對輸入進行處理，如單詞詞頻統計，排序等，完成對應業務需求。

　　3.輸出處理模塊 對結果以合理方式輸出，將單詞詞頻排序的結果輸出到文件。

　　4.主調用模塊 接受命令行數據，調用各個模塊，完成業務功能

• 測試用例設計

　　輸入：考慮到輸入的參數有多種情況：1.沒有參數 2.有一個參數但是文本類型不是txt 3.有一個參數且是.txt文本 4.有多個參數輸入

　　字符統計和處理：根據老師所羅列的規則設計各種包含- ，‘+字母等類型的文本進行測試，看程序能否正常運行

　　輸出 ：看輸出的詞頻能否先按照詞頻順序再按照字母表順序排序，設計有不同詞頻的單詞和有相同詞頻但是首字母不同的文本

• 單元測試運行截圖

• 
• 出現感嘆號是因為第一個是正確輸入，所以沒有異常拋出，後面三個都有異常
• 
• 

• 2.擴展任務

• 編程規範

　　《阿裏巴巴Java開發手冊》中指出：為了達到代碼自解釋的目標，任何自定義編程元素在命名時，使用盡量完整的單詞組合來表達其意
　　說明：如果元素命名不清晰，我們需要花額外的時間去理解函數的功能以及整體的框架邏輯

　　根據我的實踐體會舉例如下：在Main函數中設計傳遞參數的變量如存儲詞頻信息的變量時用wordsFrequency表示，而不是用簡寫的WF，容易讓人不明白變量的作用.

　　選取《阿裏巴巴Java開發手冊》第一章的命名風格規範作為評價規範

　　分析了學號為17092的同學的代碼，他的代碼有以下幾個方面的規範：

　　1.變量和方法的命名都是采用lowerCamelCase 風格,大部分遵守駝峰規則

　　2.類名使用 UpperCamelCase 風格

　　3.使用了盡量完整的單詞組合來表達其意

　　當然在某些方面也有不足，如常量沒有用大寫來表示等

• 靜態代碼檢查工具

　　名稱：Alibaba Java Coding Guidelines

　　下載地址：https://github.com/alibaba/p3c/tree/master/idea-plugin

• 掃描結果

　　代碼存在的問題：

　　1.變量名沒有符合lowerCamelCase命名風格

　　2.包名沒有用小寫

　　3.沒有添加作者信息

　　4.類名沒有使用 UpperCamelCase風格

　　改進方法：

　　1.使用lowerCamelCase命名風格重新命名變量 2.包名使用小寫形式 3. 添加作者信息 4.類名改為UpperCamelCase風格的WcPro

• 小組代碼問題：

1.一行的if/else/for\while等循環條件判斷沒有使用大括號

2.出現了未經定義的常量

3.使用了行尾註釋

4.在條件判斷中執行了復雜的語句

5.集合初始化時沒有指定大小

針對以上問題，分別將項目中的不符合規範的地方進行了修改

• 3.高級任務

  ---

• 測試集設計思路

• 程序最耗時的地方在於對文本進行判斷處理，因此如果需要加大程序的壓力，需要讓程序盡量覆蓋每一個判斷節點.根據此思路，測試數據集應該多包含覆蓋判斷節點的字符.同時文本的數據量也要比較大，我們的測試集大小為12.54M

• 程序性能指標：在程序讀取txt文件時開始計時，一直到程序將所有結果輸出到結果文件時結束的時間

• 同行評審的過程

　　 參加的人：小組成員

　　 主持人：徐江南

　　 評審人：封俊羽，李民聰，周誌為

　　 提出意見:1.程序在循環中存在重復的變量定義和空間開辟，建議將變量提出循環，提高速度 2.判斷處理可以進行優化

• 實際測試結論

• 優化前：
• 優化後：

• 優化設計思路

• 通過將循環中重復定義的變量外提，優化判斷處理，就能夠提高程序將近20%的性能

• 從開發->測試->提高質量

• 在任何時候，我們在最初所定的開發計劃，以及程序設計都不可能是一個比較好的狀態，需要通過單元測試，黑盒白盒測試，集成測試，壓力測試等等不同的測試方法去對程序進行測試以發現最開始程序設計時的不足與漏洞，及時更新叠代.通過不斷地測試，我們程序的質量也在不斷提高，效率越來越高.測試的過程其實也是一個提高自己的過程，通過測試你能夠發現自己最初設計的不足，汲取經驗，在下次進行開發時能夠設計和寫出更高效的代碼和程序

小組貢獻分 0.33

第4周小組作業：WordCount優化