第四次做業-《結對編程》

fork倉庫地址	地址
github地址	git
結對夥伴學號	201731062518
結對夥伴博客地址	夥伴博客

1.結對過程

• 在明理樓的一個教室裏一塊兒對項目進行了分析。對項目進行分工，作了需求分析。一個項目開始於需求調研，所謂「千里之行，始於足下」、「好的開始是成功的一半」、作到事半功倍，有了好的需求分析，對於項目的順利開展很重要，尤爲是能夠避免後期開發過程出現紕漏。而後討論了要寫多少類，咱們一人負責一塊，我負責接口方面，夥伴則負責調用方面。已經把類名、方法那些定義好了，這樣整合起來代碼可以跑起來。
  
  在接口的設計過程當中，我按照題目的要求設計了計算總字符個數、計算文本中總單詞數、計算文本總行數、計算文本中每一個單詞出現的次數、將結果寫入文件等方法，再最初的編碼時，遇到了一些瓶頸，也是網上找方法、查資料，才解決了的。在代碼複審的過程當中，我和夥伴發現了我本身有些方法寫的不是很好，邏輯上的處理有點瑕疵，而後一塊兒商討進行了改進。
  
  而後參考了c#的代碼規範，就開始了代碼的編寫，最後把兩我的的整合起來，進行單元測試和結果測試，而後往GitHub上面迭代傳送。
  
  結對以下圖：
  

  2.psp表格

  PSP2.1	personal software process stages	預估耗時（分鐘）	實際耗時（分鐘）
  planning	計劃	35	45
  estimate	估計這個任務須要的時間	65	60
  development	開發	50	60
  analysis	需求分析（包括學習新技術）	15	15
  design spec	生成設計文檔	10	15
  design review	設計複審（和同事審覈設計文檔）	10	10
  coding standard	代碼規範（爲目前的開發制定合適的規範）	5	5
  design	具體設計	20	30
  coding	具體編碼	90	120
  code review	代碼複審	45	60
  test	測試（自我測試，修改代碼，提交修改）	60	80
  reporting	報告）	100	100
  test report	測試報告	45	50
  size measurement	計算工做量	20	20
  postmortem&process improvement plan	過後總結，並提出過程改進計劃	15	10

  3.解題思路分析

• 咱們這裏設計了一個count接口，以及count接口的實現類，再來一個調用類。最後再來一個單元測試類。接口裏面有計算總字符個數、文件中總單詞數、文本總行數、每一個單詞出現的次數、寫入文件的方法。而後就是各個方法就是去實現項目所要求的基本功能。
  
• program類:調用接口實現類
• Count接口：定義方法
• count類：實現接口，實現其方法
• 程序流程圖：
  
• 如何體現"Design by Constract"、"Information Hiding"、"Interface Design"、"Loose Coupling"等原則
• Design by Constract(契約式設計)：按照某種規定對一些數據等作出約定,若是超出約定,程序將再也不運行,例如要求輸入的參數必須知足某種條件。
• Information Hiding(信息隱藏):是指設計和肯定模塊時，使得一個模塊內包含的特定信息（過程或數據），對於不須要這些信息的其餘模塊來講，是不可訪問的。
• Interface Design(接口設計):設計接口分析的角度要統一明確。接口的命名要規範。

• Loose Coupling(鬆耦合)：鬆耦合的目標是最小化依賴。鬆耦合這個概念主要用來處理可伸縮性、靈活性和容錯這些需求。同時意味着更多的開發以及維護工做量。

  4.設計實現過程

• 1.Count接口中的方法
  

• 2.count去實現該接口，具體把方法實現出來
  
  
  這裏設計好後，和隊友的整合起來。在本身桌面上建立兩個txt文件，3.txt是讀入文件，4.txt是寫入文件。
  運行後結果以下圖：
  

  5.代碼複審

• 咱們的功能是分開寫的，全部沒整合以前是不知道整合起來代碼到底能不能能跑起來。代碼的規範來講，咱們兩我的寫的仍是合乎要求，兩個對代碼進行互評，查找錯誤的地方。
• 兩個整合事後，對代碼進行運行，發現報了一堆錯，多是兩個整合起來，對象名沒一致，致使的錯誤。
• 有助於雙方熟悉對方寫的代碼。
• 查到了本身的有些邏輯上的錯誤，同時隊友還給出了優化算法的建議。
• 後面在cmd裏面運行時發現輸入命令後，並無跳出正確的結果，才發現本身寫接口方法的時候，沒有寫輸出路徑。這個是隊友幫我發現的

• 代碼規範(參考)--規範的代碼
  
  規範的代碼能夠提升開發效率。
  
  養成代碼規範的習慣，有助於自身的成長。
  
  規範的代碼能夠下降維護成本。
  

  6.單元測試

• 單元測試以下：
  
  發現出錯了，修改代碼中assert.areEqual方法中的參數，成功經過測試，也成功讀入測試的輸出目錄。
  

  6.接口性能改進和測試

• 這裏對接口進行改進，是我結對隊友想出來的。設計一個抽象Statistical類，最後將具體詞頻統計的各個功能進行分離，使用工廠方法模式，將代碼重構，方便了以後若是要增長其餘功能，可直接添加其餘具體操做詞頻的具體工廠便可，就無須整個改動代碼。
  

• 性能測試
  
  

  7.異常處理說明

• 假如在cmd裏面輸入非項目要求的命令，就會報錯。咱們這裏使用了數組限制了輸入的命令。
  
  解決這裏異常，咱們可使用try 和catch塊提供得一種結構化的異常處理方案，try catch自己並不會影響系統的性能，在沒有發生異常的時候try catch是不會影響系統性能的。受影響的時候是發生異常的時候。

  8.附加功能

• 支持兩種導入單詞文本的方式：①導入單詞文本文件，②直接在界面上輸入單詞並提交
  提供可供用戶交互的按鈕和，實現-i -m -n -o 這四個參數的功能，對於異常狀況須要給予用戶提示。
  將結果直接輸出到界面上，並提供「導出」按鈕，將結果保存到用戶指定的位置。
  結合博客要求增長的功能，這裏我和隊友對發佈的要求的理解「提供可供用戶交互的按鈕和，實現-i -m -n -o 這四個參數的功能」應該就是設計一個能夠供用戶與系統交互的界面，也就是實現咱們以前設計的cmd讀入-i -m -n -o命令的效果。設計效果以及最終測試以下：
  首界面：
  
  導入文件：
  
  
  
  結果以下：
  

  9.上傳github

• 在本地上往本身Github倉庫先傳入文件，提交了三次。
  
  
  再簽入老師GitHub。
  

10.總結

• 在結對的過程當中仍是有所收穫的，雖然兩我的的編碼能力不一樣，咱們仍是積極探討如何才能把項目作到最後，兩我的各負責一個版塊，最後再結合起來。這樣作的話，前期要把需求分析作好，才能避免後面兩人產生分歧。整體來講，我感受咱們可能作到了1+1=2，恰到好處的那種，兩我的在最終的整合階段，相互給對方寫的版塊提出一些改進上的建議。此次結對編程我也學到了不少，要作到前車可鑑，不能盲目的就直接開始敲代碼；兩我的要熟悉對方的工做方式，要團結一致，互相激勵，遇到問題一塊兒分析解決。