結對第二次-文章摘要熱詞統計



1、PSP表格

PSP2.1 Personal Software Process Stages 預估耗時(分鐘) 實際耗時(分鐘)
Planning 計劃
• Estimate • 估計這個任務須要多少時間 610 630
Development 開發
• Analysis • 需求分析 (包括學習新技術) 70 90
• Design Spec • 生成設計文檔 60 50
• Design Review • 設計複審 30 50
• Coding Standard • 代碼規範 (爲目前的開發制定合適的規範) 30 30
• Design • 具體設計 70 80
• Coding • 具體編碼 320 300
• Code Review • 代碼複審 30 30
• Test • 測試(自我測試,修改代碼,提交修改) 40 60
Reporting 報告
• Test Report • 測試報告 60 90
• Size Measurement • 計算工做量 30 40
• Postmortem & Process Improvement Plan • 過後總結, 並提出過程改進計劃 40 55
合計 740 820



2、解題思路描述

針對基本需求:

  • 在考慮統計文件的字符數時,咱們採用的是直接用字節流讀入文件,而後判斷讀入字節的ascii碼進而統計字符數。在考慮統計文件的單詞數時,咱們採用本次改用字符串流讀入文件。每次讀入一整行的字符串。而後用正則表達式篩選出知足條件的單詞,再用split函數和正則表達式進行分割,而後統計單詞數量。而每次讀一整行字符串,對該字符串的每一個字節進行逐個判斷,若是找到知足條件的字符,則該行是有效的,不然無效。接着將單詞和頻數存入,HasmMap集合中,而後寫一個判斷函數,對HashMap集合中的單詞按要求進行排序。最後直接用字符流將結果存入result.txt文件中。
  • 在接口封裝上,咱們已經儘可能將每一個功能單獨包裝成一個函數,可是因爲編程能力不足,並沒對這些東西進行徹底封裝,望諒解。git

    針對進階需求:

  • 爬蟲部分因爲時間緊迫,且我對這方面沒有任何經驗,因此並無寫爬蟲,所用的測試文件,是從其餘同窗那裏借過來的。自定義輸入輸出: 從args[]中讀入命令行參數中輸入路徑和輸出路徑便可。檢測args中是否有字符串」-w」若是有,則進行單詞權重計算,不然不進行。檢測到字符串」-w」,再進行」Title:」和」Abstact:」的判斷,而後將HashMap集合中的詞頻進行更改便可。該問題我認爲應該用正則表達式進行匹配,可是我沒有寫出知足條件的正則表達式,因此這沒有解決。判斷args[]是否有字符串」-n」如有,則在進行HashMap集合的迭代是,加入迭代次數的統計和判斷便可。可是沒能完成該功能。還有就是對於附加題沒能解決。github

3、設計實現過程

--------正則表達式

4、改進程序上花費的時間及改進思路


實際上,在寫程序的時候,咱們是邊推動,變修改的。當每個功能實現以後咱們都會進行測試,可是當在寫一個功能以後,老是會發現上一個功能好像須要傳一些參數或者返回個什麼到下一個功能上,因此改進程序花費上的時間應該是很是多的。差很少和編寫新功能的時間是同樣。在此次做業中,遇到的最大的一個坑,就是字符串流和字節串流的不一樣。字符串流遇到\n會自動省略並,而字節串流則會將其讀入。編程

5、代碼說明

--------



函數

6、單元測試代碼(部分)

--------沒有撰寫自動測試代碼單元測試

7、遇到的困難以及解決辦法

--------1.字符串流讀取不到\n.改用字節流讀取解決
--------2.爬蟲的問題不會編寫,沒能解決
--------3.進階需求中,多個單詞組成詞組的匹配,有想過用正則表達式解決。可是沒能寫出知足條件的正則表達式.學習

8、評價隊友

林鵬飛:測試

對於林鵬飛同窗,代碼的部分基本上都是由他負責,對於整個項目的分工和每一個部分的安排他都作的很是好,我要向他學習這種全局的規劃以及對整個項目的安排能力。他對於問題的解決能力很強。
徐炳南:
對於徐炳南同窗,他常常會和鵬飛一塊兒討論一些問題,且會經過各類辦法去解決。可是代碼能力還須要提升。編碼

相關文章
相關標籤/搜索