1、 Github地址:java
https://github.com/RuiBingo/PersonalWorkgit
2、我的PSP表格:github
PSP2.1正則表達式 |
PSP階段數組 |
預估耗時(分鐘)編輯器 |
實際耗時(分鐘)佈局 |
Planning學習 |
計劃測試 |
60 ui |
20 |
· Estimate |
· 估計這個任務須要多少時間 |
60 |
20 |
Development |
開發 |
1200 |
1080 |
· Analysis |
· 需求分析 |
120 | 100 |
· Design Spec |
· 生成設計文檔 |
30 | 30 |
· Design Review |
· 設計複審 |
30 | 30 |
· Coding Standard |
· 代碼規範 |
60 | 50 |
· Design |
· 具體設計 |
60 | 30 |
· Coding |
· 具體編碼 |
900 | 1000 |
· Code Review |
· 代碼複審 |
30 | 30 |
· Test |
· 測試(自我測試,修改代碼,提交修改) |
180 | 150 |
Reporting |
報告 |
120 | 100 |
· Test Report |
· 測試報告 |
60 | 60 |
· Size Measurement |
· 計算工做量 |
30 | 20 |
· Postmortem & Process Improvement Plan |
· 過後總結, 並提出過程改進計劃 |
60 | 50 |
合計 |
3000 | 2770 |
3、解題思路
剛開始看到題目的時候就以爲這個項目其實相似於以前java課設要求作的文本編輯器,首先循序漸進實現基礎功能,擴展功能,最後再實現高級功能,而後將實現功能的方法都彙總到含有主程序功能的類裏實現。首先基礎功能即查詢字符數、行數和單詞數是同樣的,而後對於擴展功能查詢註釋行數、空白行數和代碼行數功能我一開始的想法就是查詢代碼其實相似於基礎功能,但判斷時能夠採用正則表達式去判斷,關鍵是那個遞歸調用的功能,一開始看項目的想法就是:遞歸其實也很簡單,寫一個方法調用上述功能而後設置條件語句進行判斷後遞歸就能夠。但恰恰在實踐作的時候由於某些緣由讓個人遞歸功能並不如意,我花了不少的時間在想辦法改善,具體緣由就下面分開細講了,高級功能就我認爲最簡單了,作個基本的圖形界面,用java插件不用一分鐘就作出來了,當基本功能和擴展功能都實現了,再把這些功能調用進去就ok了!接下來細講下每一個功能的基本實現思路:
① 首先是基本功能,-c查詢字符數,-l查詢行數,-w查詢單詞數,這三個最簡單的功能在以前已經實現過了,但因爲以前的代碼我找不到了,因而就從新打一遍,思路就是利用文件輸入流獲取內容,而後循環判斷每行有多少字符,總共有多少行數,單詞數的統計就利用簡單的正則表達式就能夠了。思路簡單就不細講了,代碼看一眼都能懂。
② 而後接着實現擴展功能,我首先作的是-a,即查詢註釋行數,空白行數和代碼行數,這個也是弄個文件輸入流獲取內容而後利用正則表達式對註釋行數和空白行數進行判斷,對於註釋行的判斷利用「//」和「/*,*/」這三種字符樣式進行查找標記,即在每一行內容的查找中發現「//」就讓註釋行數+1,而後利用String類裏的trim()方法切割掉每一行兩端的空格字符,並用startsWith()方法對查找到的「/*」進行標記,用endsWith()方法對「*/」進行標記,從找到「/*」開始到找到「*/」結束統計註釋行數,再加上以前統計的就是總的註釋行數了。對於空白行數的判斷一開始使用了正則表達式,但發現我寫的正則表達式判斷老是不許確,後來上網查資料知道了利用isEmpty()這個方法加上對每一行的「{」和「}」進行標記去判斷空白行數,最後是對代碼行的判斷,個人想法是既然不是註釋行也不是空白行那就是代碼行咯!因而用條件語句把前兩種都判斷不是的行數算成代碼行++,就獲得代碼行數了。
③ 而後是這個一開始覺得簡單的遞歸調用功能-s,一開始我並無利用好通配符這個條件,而是在一個方法裏面讓用戶輸入想匹配的後綴名(例如,用戶相匹配後綴名爲「txt」的就直接輸入txt就能夠了),而後用foreach循環找出路徑中的全部文件,利用正則表達式去匹配這些文件名,若匹配到txt就輸出文件名並調用上述查詢功能輸出統計結果,但這個方法有個bug,就是一旦循環到的是目錄的話就是要從新遞歸這個方法,而後又要從新問一遍用戶想匹配的後綴名,用戶又要從新輸入一遍,就很蠢,因而我開始嘗試將用戶輸入的後綴名這段代碼移出方法,就不用每次遞歸都要從新詢問,但嘗試了很久都失敗了,這就是前面說的一開始以爲遞歸很簡單,但作的時候花了不少時間。後來跟同窗交流才發現他們都是去切割通配符而後匹配的,因而我刪除了我原來的方法,而後利用正則表達式去切割用戶輸入的含有通配符的路徑,切割完剩下前面的路徑和後面的後綴名兩部分存入數組,而後做爲參數傳回遞歸方法中,也是用foreach找出全部文件,若是匹配的數組前半部分的路徑就從新遞歸調用,若是是匹配後半部分的後綴名就調用功能輸出統計結果。
④ 最後是圖形界面GUI的實現,即功能-x的實現,java作圖形界面我都是用插件直接設置好絕對佈局後,添加按鈕button和一個文本框TextArea,而後給按鈕設置一個監聽器,點擊他既能夠選擇文件,而後調用方法對選擇的文件進行統計,輸出在文本框中。
⑤ 上述四個步驟我都是放在三個類裏面,其中①和②放在類countWord,③放在類fangfa中,④就是單獨一個類GUI01。而後再建一個command類放執行程序,集合其他三個類的功能,並輸出命令界面,供用戶選擇,當用戶輸入路徑時,利用正則表達式判斷用戶輸入格式的對錯,並利用if和switch條件語句進行功能的選擇。
4、設計實現過程
類command經過判斷用戶輸入的路徑進行判斷,如果含有通配符的文件則調出-s功能,如果不含通配符的文件則調出-c,-l,-w,-a,-x功能。路徑錯誤則從新讓用戶輸入,-x功能直接彈出圖形界面框。
5、測試
①wc exe功能界面展現:
②創建測試文檔:
③各個功能的測試:
-c,-l,-w,-a功能展示:
-x功能展示:
-s遞歸功能展示:
6、我的總結
經過此次項目我意識到了之前學習的java知識都忘了不少,看來代碼一段時間不打仍是很容易生疏啊,之後仍是要多打點代碼,此次我的項目的設計我是邊回顧之前的知識一邊作,中途有不少忘記的方法也是經過找資料纔想起來,在這個過程當中我遇到了幾個bug,有時一直找不出問題在哪比較煩躁,但其實問題很顯眼,過於浮躁大大下降了個人工做效率,遇到難題仍是要先休息下放空大腦,只要頭腦清醒,而後把一個大的難題慢慢分紅一個小難題去解決,很快你就會發現這個難題已經不算是難題了。