博文簡要信息表html
項目 | 內容 |
---|---|
這個做業屬於哪一個課程 | 軟件工程 |
這個做業的要求在哪裏 | 軟件工程結對項目 |
課程學習目標 | 熟悉軟件開發總體流程提高自身能力 |
本次做業在哪一個具體方面幫助咱們實現目標 | 第一次體驗一個完整的工程 |
點評信息java
點評博客 | 王立新的博客 |
---|---|
github地址 | 王立新的github |
兩兩自由結對,對結對方的《實驗二 軟件工程我的項目》的項目成果進行評價
博文總體結構符合要求、 博文內容詳實可是博文中對重點沒有突出,但願之後多加粗或者改變字體顏色進行突出顯示,使閱讀借鑑者更清晰明瞭的抓住重點,節省閱讀時間提升效率。
PSP中「計劃共完成須要的時間」與「實際完成須要的時間」兩列數據的差別化主要有一下幾點:
對於具體任務操做步驟不熟練,沒有掌握好任務時間。
編程能力的欠缺,致使在編程過程當中花費了大量時間,而且尚未實現所有的功能。
在軟件測試過程當中軟件的健壯性不夠,代碼沒有模塊化,閱讀花費了很多時間,運行比較耗時。
心得
此次結對的搭檔是個人一個舍友,所以前期的交流問題不是不少。一開始的問題就是用誰的做業3和用誰的開發工具,通過一點討論纔有的結果。還有就是關於文件流的用法,咱們都有一些我的的見解,後來仍是在網上搜索了下用法,纔有這最後的最終版本。對於過程當中的模塊化存在的問題仍是比較嚴重。git
源碼地址
源碼可在此處查看github
結對項目實施
需求分析
根據實驗四 軟件工程結對項目所提要求,咱們分析的主要需求有:
(1)實驗二要求的功能;
(2)單詞頻數可視化柱狀圖要求是如下樣式:
(3)統計該文本行數及字符數;
(4)各類統計功能均提供計時功能,顯示程序統計所消耗時間(單位:ms);
(5)可處理任意用戶導入的任意英文文本;
(6)人機交互界面要求GUI界面(WEB頁面、APP頁面均可);
(7)附加分功能:統計文本中除冠詞、代詞、介詞以外的高頻詞;
(8)附加分功能:統計前10個兩個單詞組成的詞組頻率。
軟件設計
本次使用告終構化設計的理念,故只有一個主類(WordCount)其設計流程以下:
核心功能代碼展現:展現核心功能代碼算法
public static void main(String[] args) throws FileNotFoundException,IOException{ try{ //使用流的方法讀取文件 BufferedReader br = new BufferedReader(new FileReader( "F:\\javademo\\softwar_pro\\MRDemo\\words.txt")); //使用TreeMap方法自動將結果按Integer列 TreeMap<String,Integer> treemap = new TreeMap<String,Integer>(); //用來存儲讀取的單詞 String readLine = null; //記錄單詞的總數 int count = 0; while((readLine = br.readLine())!=null){ //將字母排序爲小寫 readLine = readLine.toLowerCase(); //將全部單詞以大寫輸出 //readLine = readLine.toUpperCase(); //過濾出只含有字母的字段 String[] str = readLine.split("[\\s]"); //過濾掉多個空格,「+」表明多個空格的意思 for(int i = 0;i<str.length;i++){ count++; String word = str[i].trim();//trim()用來去掉字符串首尾的空格 if(treemap.containsKey(word)){//判斷此映射是否包含指定鍵的映射關係 treemap.put(word, treemap.get(word)+1); }else{ treemap.put(word, 1); } } }
Iterator<Map.Entry<String,Integer>> it = treemap.entrySet().iterator(); //判斷是否存在下一個單詞 while(it.hasNext()){ Map.Entry<String, Integer> entry = it.next();//獲取map中每個鍵值 //輸出結果 System.out.println(entry.getKey()+" "+entry.getValue()); br.close();//關閉流 } System.out.println("單詞總數爲:"+count+"個"); }catch(FileNotFoundException e){//異常處理 e.printStackTrace(); }catch(IOException e){ e.printStackTrace(); }
程序運行:程序運行時每一個功能界面截圖
編程
描述結對的過程,提供兩人在討論、細化和編程時的結對照片(非擺拍)
模塊化
提供這次結對做業的PSP工具
任務內容 | 計劃共完成須要的時間(min) | 實際完成須要的時間(min) |
---|---|---|
計劃 | 10 | 5 |
估計這個任務須要的時間,並規劃大體工做步驟 | 5 | 3 |
開發 | 100 | 120 |
需求分析(包括學習新技術) | 7 | 9 |
生成設計文檔 | 15 | 20 |
設計複審 | 5 | 7 |
代碼規範(爲目前的開發制定合適的規範) | 5 | 5 |
具體設計 | 6 | 8 |
具體編碼 | 60 | 80 |
代碼複審 | 10 | 25 |
測試(自我測試、修改代碼、提交修改) | 10 | 8 |
報告 | 20 | 25 |
測試報告 | 10 | 10 |
過後總結,並提出過程改進計劃 | 25 | 20 |
從PSP表中能夠發現項目在實施工程中的時間比預計時間要長,可能和本身對開發流程不熟悉、算法設計不精有關。在之後的 開發中要多加改進。性能
心得體會
這是第一次嘗試結對編程,感受還蠻不錯的。「寸有所短,尺有所長」,兩我的的組合果真大大的下降了錯誤的發生率,提升了效率。注重細節的,能減小低級錯誤的發生;看中總體的,能從大方向上把握。儘管是對前面做業的複審與再編,可是經過此次做業也改正了我的編程時的一些不良習慣,汲取了小夥伴身上的優勢,互惠互利吧。儘管在編程時咱們會互不相讓,但這也算是另外一種收穫吧。同時,我也體驗到了代碼複審的好處。它能讓我調整前面的錯誤,優化完善程序,提升程序的性能。雖然說是一次小小的練習,但我想我會把複審應用在之後的編程中的,畢竟常常複審複審也許能提升自個人能力呢!
之前咱們也一塊兒討論過很多在各自編程中遇到的問題,可是因爲不瞭解具體內容每每沒法戳中要點,可是不得不說的是,當你在遇到問題而煩躁的時候,找我的交流一下問題,即便沒法獲得解決方法,也會使本身的思惟有改變。
結對編程能是雙方互相督促,一我的工做的時候另外一我的能夠充當一下程序猿鼓勵師因爲各自的編程習慣不一樣,代碼看起來有點亂(規範很重要啊)思考問題的角度不一樣遇到問題想到的解決方法也不同,多個思路多條活路吧。一我的工做一我的思考,輪流進行,以致於身體不會很疲憊出錯後找緣由有點小麻煩(看別人的代碼果真不是一件簡單的事情:規範確實很重要)學習