博客做業地址:http://www.javashuo.com/article/p-fpaqgolf-bp.htmlhtml
碼雲地址:https://gitee.com/piraat/PairProject-C/tree/mastergit
學號:201621123053正則表達式
同伴博客地址:http://www.cnblogs.com/ACmilan1899kaka/p/9756046.html編程
碼雲地址:https://gitee.com/milan_kaka/PairProject-Java數組
PSP2.1 | 我的開發流程 | 預估耗費時間(分鐘) | 實際耗費時間(分鐘) |
---|---|---|---|
Planning | 計劃 | 10 | 19 |
· Estimate | 明確需求和其餘相關因素,估計每一個階段的時間成本 | 10 | 19 |
Development | 開發 | 320 | 251 |
· Analysis | 需求分析 (包括學習新技術) | 20 | 10 |
· Design Spec | 生成設計文檔 | 10 | 5 |
· Design Review | 設計複審 | 10 | 6 |
· Coding Standard | 代碼規範 | 10 | 5 |
· Design | 具體設計 | 60 | 19 |
· Coding | 具體編碼 | 100 | 72 |
· Code Review | 代碼複審 | 10 | 12 |
· Test | 測試(自我測試,修改代碼,提交修改) | 100 | 112 |
Reporting | 報告 | 35 | 32 |
· | 測試報告 | 10 | 20 |
· | 計算工做量 | 10 | 6 |
· | 並提出過程改進計劃 | 15 | 6 |
這次實驗增長了幾個新功能,並加入了GUI,我主要負責的是新功能的模塊。由於上次實驗中的代碼耦合性不算高,因此這次主要內容在於解決按照要求的詞組進行排序。一開始我想運用正則表達式進行匹配:以\b[a-zA-Z]{4,}[A-Za-z0-9]爲基礎,要求多少個詞組就在後面跟上多少個[^0-9a-zA-Z]+[a-zA-Z]{4,}[A-Za-z0-9]。然而,我在嘗試之後才發現,這樣匹配一個單詞只能出如今一個詞組中,沒法達到要求中的詞組匹配。因此,由於正則表達式學的不到位,沒法寫出符合要求的正則表達式。我選擇運用笨辦法,就是先將全部輸入的單詞整理進arraylist,而後再將他們按照要求分類放入map中 String[] phraseTmp = new String[phraseNum];
這樣雖然效率低,但總算保證符合要求。
新功能做爲一個新函數,重載了上一次寫的函數,加入了新的 int phraseNum
`參數。不足的點在於,由於一開始我但願直接運用正則表達式進行匹配,因此沒有想要將整理單詞列表做爲一個單獨的函數提出來。這也就形成了兩個方法都須要分別進行單詞的提出,天然而然的下降了效率。函數
單元測試相對上一次來講改動不大,主要是增長了對詞組的測試單元測試
PS.圖形界面在同伴上的基礎上增長了一些功能學習
我負責的值得說明的代碼部分主要是詞組部分。我運用的是笨辦法,首先建立與詞組要求的詞彙數量相同的字符串數組,這樣能夠保證保存下全部詞組不會有遺漏。測試
先用for循環將前幾個詞分別保存在相應的字符串中,一直循環到第一個字符串詞數量達到要求。而後將第一個字符串存入map中
ui
而後,每遇到一個詞都將其存在全部字符串中,每當一個字符串滿就將其與map中存入的詞組比對,若是不一樣則加入,相同則value加一。
圖形界面我並無寫太多,主要是添加了由單選框控制的文本輸入phraseN.setEditable(phraseNumB.isSelected());
與文件選擇的JFileChooser chooser = new JFileChooser();
由於我沒有運用stringbuilder,而是對字符串直接"+",因此可能拖慢了速度。
我的感覺:
結對編程經歷
這次關於結對編程的實踐經歷既有咱們自認爲作的不錯的地方,也有須要改進的地方。
咱們的優勢在於分清楚了兩我的都須要作什麼,因此在作的時候並無感受不習慣,也沒有由於本身的編程問題給對方帶來麻煩。
須要改進的地方則是咱們沒有將函數名稱等問題統一,這給咱們後續進行編程帶來了必定的麻煩。咱們應該儘早肯定下一些標準,例如兩我的共同商定着寫一些接口文件,肯定參數的共同名稱等等。在接下來的團隊編程中這是我尤爲要注意的地方。