第四周作业wcPro
github地址：https://github.com/muzhailong/wcPro.git
PSP2.1表格
| PSP2.1 | PSP階段 | 預估耗時 （分鐘） | 實際耗時 （分鐘） |
| Planning | 計劃 | ?40 | ?20 |
| · Estimate | · 估計這個任務需要多少時間 | ?30 | ?20 |
| Development | 開發 | ?300 | ? |
| · Analysis | · 需求分析 (包括學習新技術) | ?60 | ?40 |
| · Design Spec | · 生成設計文檔 | ?10 | ?10 |
| · Design Review | · 設計復審 (和同事審核設計文檔) | ?10 | ?10 |
| · Coding Standard | · 代碼規范 (為目前的開發制定合適的規范) | ?20 | ?10 |
| · Design | · 具體設計 | ?40 | ?30 |
| · Coding | · 具體編碼 | ?120 | ?100 |
| · Code Review | · 代碼復審 | ?10 | ?10 |
| · Test | · 測試（自我測試，修改代碼，提交修改） | ?40 | ?50 |
| Reporting | 報告 | ?20 | ?20 |
| · Test Report | · 測試報告 | ?10 | ?10 |
| · Size Measurement | · 計算工作量 | ?10 | ?10 |
| · Postmortem & Process Improvement Plan | · 事后總結, 并提出過程改進計劃 | ?10 | ?10 |
?
??
?接口實現：
我們小組講這個工程分成類7大模塊：
? ? ? ? ? ? param：參數解析模塊
? ? ? ? ? ? ? ?in? ? ?：輸入模塊
? ? ? ? ? ? ? ?core? ：核心處理模塊
? ? ? ? ? ? ? ?out? ? ?：輸出模塊
? ? ? ? ? ? ? ? ui? ? ：圖形界面模塊
? ? ? ? ? ? ? ? util? ：工具類模塊
? ? ? ? ? ? ? ? start： 模塊集成模塊
? ? 我主要負責的是輸出模塊，各個模塊如下圖所示：
????
輸出控制模塊：
public class WordPrinter {
private List<Entry<String, Integer>> res;
private PrintWriter writer;
public WordPrinter(List<Entry<String, Integer>> res,PrintWriter writer) {
this.res = res;
this.writer=writer;
}
public void print() {
int sz=res.size();
Entry<String, Integer> tmp=null;
for(int i=0;i<sz-1;++i) {
tmp=res.get(i);
writer.write(tmp.getKey()+" "+tmp.getValue()+"\r\n");
}
tmp=res.get(sz-1);
writer.write(tmp.getKey()+" "+tmp.getValue());
writer.flush();//刷新緩沖
}
}
為了方便輸出，使用Map.Entry類來保存字符的名稱，以及出現的頻率。
使用Print Writer將要輸出的數據寫入文件中。
?
測試用例：
?
測試用例的設計主要分模塊內測試和模塊間測試（集成測試）可以點擊查看。
? ? ? ?
?
單元測試截圖：
start：
in：
core：
評價單元測試用例效果：
感覺我做的單元測試用例挺好的大部分都符合單元測試的集合要素（貌似是：自動化，靈活，數據集合，報告記錄）。start模塊主要采用的是黑盒測試，因為start模塊集成了所有的模塊，白盒測試部分只是做了一部分的判斷邏輯等。in模塊應該來說是測試最為復雜的模塊，內部方法比較多，針對每一個方法進行測試然后使用套包的方法測試，效率還是挺不錯的。core模塊相應的邏輯比較少，因為core模塊的很多東西都依賴與in模塊，所以就對接口的相關地方進行的白盒測試。
?評價被評測模塊的質量水平：
start模塊：中
in模塊：高
core模塊：高
開發規范說明：
開發規范采用的是《阿里巴巴Java開發手冊終極版v1.3.0.pdf》
選定的開發規范以及理解(我用以下的規范檢查我的代碼)：
? ? ? ?常量定義
1. 【強制】不允許任何魔法值（即未經定義的常量）直接出現在代碼中。
理解：就是說常量不能使用變量拼接而成的。
反例：int c；static int A=c；
?
2. 【強制】long 或者 Long 初始賦值時，使用大寫的 L，不能是小寫的 l，小寫容易跟數字 1 混 淆，造成誤解。
理解：很簡單不解釋
舉例：long k=123L;
3. 【推薦】不要使用一個常量類維護所有常量，按常量功能進行歸類，分開維護。 說明：大而全的常量類，非得使用查找功能才能定位到修改的常量，不利于理解和維護。
理解：有時候我們會專門寫一個類來維持常量，這樣是不好的因為將所有的常量放在一起就像一個大雜燴一樣。應該根據功能進行放置，比如說和單詞容量有關的常量可以放在單詞的工廠類中。
代碼格式
1. 【強制】大括號的使用約定。如果是大括號內為空，則簡潔地寫成{}即可，不需要換行；如果 是非空代碼塊則：
1） 左大括號前不換行。
2） 左大括號后換行。
3） 右大括號前換行。
4） 右大括號后還有 else 等代碼則不換行；表示終止的右大括號后必須換行。
理解：就是字面意思，不用解釋。
舉例：while(i){
......
}
2. 【強制】 左小括號和字符之間不出現空格；同樣，右小括號和字符之間也不出現空格。
舉例：void king();
3. 【強制】if/for/while/switch/do 等保留字與括號之間都必須加空格。
說明：格式上看的清晰一點。
反例：if(t<0){
.......
}
4. 【強制】任何二目、三目運算符的左右兩邊都需要加一個空格。
舉例：k = i + j;
5. 【強制】采用 4 個空格縮進，禁止使用 tab 字符。
說明：很多IDE都可以講tab設置為4個空格。
6. 【強制】注釋的雙斜線與注釋內容之間有且僅有一個空格。
舉例：// fjei
7. 【強制】方法參數在定義和傳入時，多個參數逗號后邊必須加空格。
舉例：void f(int a, int b, int c)
??OOP 規約
1. 【強制】避免通過一個類的對象引用訪問此類的靜態變量或靜態方法，無謂增加編譯器解析成 本，直接用類名來訪問即可。
理解：靜態方法屬于類，和類是綁定的，通過對象還要先找到類，在從類找到方法。
舉例：
public class Test{
public static int a；
}
使用Test.a即可。不需在定義一個引用。
2. 【強制】所有的覆寫方法，必須加@Override 注解。
理解：Override注解貌似是編譯時檢查，如果重載出現問題編譯時不會通過的。
舉例：
public class Animal{
public void voice（）{}
}
public class Duck extends Animal{
@Override
public void voice（）{}
}
3. 【強制】不能使用過時的類或方法。
理解：一般來說過時的方法都會有風險，或者效率問題。
舉例：acm中最喜歡用的StreamTokenizer
4. 【強制】構造方法里面禁止加入任何業務邏輯，如果有初始化邏輯，請放在 init 方法中。
理解：講邏輯放在構造方法中會造成構造對象浪費大量的時間，有些對象構造了但不一定會使用。
舉例：略。
5. 【推薦】循環體內，字符串的連接方式，使用 StringBuilder 的 append 方法進行擴展。
理解：+相當于使用多個StringBuilder對象，效率很低下。
舉例：String a="asd";
a=a+"few"+"few";
正例：StringBuilder a=new StringBuilder（）；
a.append("fewf");
a.append("dsfew");
6. 【推薦】類成員與方法訪問控制從嚴：
1） 如果不允許外部直接通過 new 來創建對象，那么構造方法必須是 private。
?2） 工具類不允許有 public 或 default 構造方法。
3） 類非 static 成員變量并且與子類共享，必須是 protected。
4） 類非 static 成員變量并且僅在本類使用，必須是 private。
5） 類 static 成員變量如果僅在本類使用，必須是 private。
6） 若是 static 成員變量，必須考慮是否為 final。
7） 類成員方法只供類內部調用，必須是 private。
8） 類成員方法只對繼承類公開，那么限制為 protected。
理解：這個符合最小訪問原則。
1. 【推薦】集合初始化時，指定集合初始值大小。
理解：ArrayList默認大小是10 Map的默認大小是16，他們一般都會在容量達到75%的時候進行擴容處理，所以如果初始時候知道了容量可以避免擴容的開銷，提升效率。
舉例：
List<String> a = new ArrayList<String>(100);?
2. 【推薦】使用 entrySet 遍歷 Map 類集合 KV，而不是 keySet 方式進行遍歷。
理解：看過Map源碼就知道，HashMap在內部維持了一個Entry的數組，使用entrySet遍歷其實就是遍歷數組，如果使用keySet就行遍歷，是講所有的key打包成一個set然后再通過遍歷key從map中獲取相應的value，效率低下。
舉例：
for（Map.Entry<String,Integer>e : map.entrySet()）{
.....
}
?
存在的問題：
代碼的注釋比較少，讓人摸不著頭腦。
變量命名意義不是很明顯。
優化環境：
文件大小：40M
默認時間：3.911
優化策略：
in模塊
1.改變緩沖區大小，減少讀文件次數 默認是1個字節 改變為4k
CACHE_CAPACITY=4*1024；
時間：2.178
2.StringBuilder對象設置為靜態的 實現重用
時間：2.124
3.設置StringBuilder對象較大的容量，從而避免頻繁的擴展容量：
WORD_LENGTH=10
時間：2.156
WORD_LENGTH=10
時間：2.113
影響不是很大
core模塊
1.設置Map較大的容量，從而減少沖突；
默認是16
MP_CAPACITY=1M 時間：2.012 最優
MP_CAPACITY=40M 時間：3.296
MP_CAPACITY=20M 時間：2.581
MP_CAPACITY=16M 時間：2.473
MP_CAPACITY=4M 時間：2.427
MP_CAPACITY=1K 時間：2.241
2.改變排序方法
默認采用堆排序 最優
使用快速排序：慢
總結：
沒有軟件開發就沒有測試，軟件開發提供軟件測試的對象。
軟件開發和軟件測試都是軟件生命周期中的重要部分。
軟件開發和軟件測試都是軟件過程的重要活動。
軟件測試是保證軟件開發產物質量的重要手段。
參考：
PrintWriter用法：https://www.cnblogs.com/xiaotiaosi/p/6394147.html
博客排版：http://www.cnblogs.com/kangzhishi0203/p/8691939.html
?
?
轉載于:https://www.cnblogs.com/liqia/p/8747829.html
與50位技術專家面對面20年技術見證，附贈技術全景圖總結
以上是生活随笔為你收集整理的第四周作业wcPro的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： EnvironmentError: my
- 下一篇： Python判断一个字符串是否可以转换为