結對項目-最長單詞鏈

項目	內容
做業所屬課程	2019軟件工程_羅傑
做業要求連接	結對項目做業
課程目標：	進行結對編程實踐
該做業的幫助	實踐結對編程，熟悉雙人軟工開發流程
隊友的結對項目總結	連接

一、本次做業github項目地址

二、開發前PSP表格

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

三、接口設計

看教科書和其它資料中關於Information Hiding, Interface Design, Loose Coupling的章節，說明大家在結對編程中是如何利用這些方法對接口進行設計的

• 三個概念總結以下：
  • 1.Imformation hiding:模塊內部的數據對外部調用者若不須要則不可訪問，保證模塊自身的安全性。
  • 2.Interface design:將軟件根據功能組成劃分爲模塊，各模塊經過接口交互。如此能夠將工做劃分，經過模塊的組合、拓展不斷實現更強的總體功能，同時維持程序的穩定性和安全性。
  • 3.Losse coupling:模塊之間切斷沒必要要的依賴，將本身的功能實現徹底在內部完成封裝，只提供必要的外部接口，保證各模塊交互時系統的健壯性。
• 踐行概念：
  • 1.信息隱藏：類內部數據和私有方法private，以public修飾方法時充分考慮必要性。
  • 2.接口設計：本次做業並不設計很複雜的類設計，但咱們也在並行開發前事先定義好接口，再進行實現，內部核心類的對外接口大多隻有一個工做函數完成此類職能範圍內的全部功能。
  • 3.鬆耦合：咱們的c++核心算法模塊提供完整參數的gen_chain接口，c#錯誤處理模塊接收命令行參數進行容錯處理（由於一開始設計時理解爲core模塊無需處理命令行參數異常，從而將此模塊獨立），兩者做爲總體提供給外部做業要求的API接口。

四、計算模塊接口的設計

計算模塊是項目核心，計算功能封裝在gen_chain_cpp函數接口中，重點在於從接受命令的外模塊獲取命令和單詞，調用gen_chain_cpp函數計算出最長路徑。

算法思路簡介：根據函數獲取的單詞表，從中取得有效單詞加入有效單詞表中，建單詞表的同時爲每一個單詞創建後繼表，計算入度，最終創建鄰接鏈表。以後計算路徑，對因而否有環的兩種狀況，首先會對單詞進行拓撲排序，若能順利進行拓撲排序，則是否有參數-r都採用動態規劃算法；若不能順利完成拓撲排序，則說明有單詞環存在，此時檢查是否有-r參數存在，沒有則返回異常信息，有則採用深度優先算法逐個節點進行搜索。
算法關鍵及獨到之處：在節點數據結構中同時存儲了單詞長度，所以計算時可根據-c和-w參數自由選擇路徑計算方式。在計算無環路徑時，有無首字母要求的算法存在差別：如有首字母要求，則動態規劃計算的起點只會選擇符合首字母要求的單詞，沒有首字母要求時則是會選擇入度爲0的點做爲起點進行計算。而對於有無肯定尾字母的狀況，根據動態規劃算法的結果，每個節點均會存儲以該節點爲結尾的最長鏈的路徑和長度，所以只需在獲取結果時選擇符合尾字母要求的點，選出最長路徑輸出，無尾字母要求則直接從中選出最長路徑輸出。

五、UML圖

六、計算模塊接口部分的性能改進

計算模塊接口部分的性能改進。 記錄在改進計算模塊性能上所花費的時間，描述你改進的思路，並展現一張性能分析圖（由VS 2015/2017的性能分析工具自動生成），並展現你程序中消耗最大的函數
在完成程序的基本功能後，咱們採用了一些數據對程序進行測試,在少許單詞的數據下測試，咱們修復了程序的一些邏輯問題，在可以正確運行小文本數據以後，咱們利用一些大文本數據對程序進行測試，測試結果比較使人失望：因爲數據結構的設計問題，程序出現了爆內存的問題。以後咱們經過對數據結構進行重構優化，修復了這一問題，如下是一部分性能測試截圖：


以上能夠看出耗時最多的時進行動態規劃計算時的函數，咱們的動態規劃計算性能還有提高空間。

如下是帶有-r參數且圖中有環的狀況，能夠看出searchpath做爲深度優先遞歸函數被頻繁調用：


因爲採起暴力枚舉的方法來進行有環路徑的搜索，運行速度較慢，性能仍須要改進。

七、Design by Contract, Code Contract

• Design by Contract，即契約式編程。咱們在聲明函數時對函數輸入輸出是有所設計、指望的，將這一指望明確寫出稱爲contract。

• 這一行爲的好處是每一個人在契約範圍內對本身的代碼負責，有問題時能夠迅速找到負責人。

• 在本次做業中，咱們共同開發整個項目，所以並無嚴格按照契約式編程的方式來完成程序，更多的進行口頭溝通，提升效率。

八、計算模塊部分單元測試展現

如下是單元測試覆蓋率截圖：

爲了對計算模塊所能遇到的各類狀況進行測試，咱們採用了大量測試樣例對程序進行測試，如下僅展現部分單元測試代碼：

九、計算模塊部分異常處理說明

根據可能出現的狀況，咱們對如下9種異常狀況作了處理：
一、出現除了"-r -c -w -t -h"之外的關鍵字，如"-x"

單元測試用例：

二、-c -w同時出現

單元測試用例：

三、同一種參數重複出現，如 -t a -t a 或 -w -w

單元測試用例：

四、-c和-w參數缺失

單元測試用例：

五、-h 後面缺乏字符

單元測試用例：

六、-t 後面缺乏字符

單元測試用例：

七、命令中出現多餘字符

單元測試用例：

八、文件打開失敗

九、缺乏-r參數的狀況下文本有環，該狀況由計算模塊經過拓撲排序後得出文本是否存在單詞環，返回信息給界面模塊進行異常處理

十、界面模塊的詳細設計過程

界面咱們僅採用簡單的命令行方式處理：

如下是命令行界面：

十一、界面模塊與計算模塊的對接

界面模塊的對接就是界面模塊從命令行獲取所需數據，以後調用計算模塊方法對計算模塊進行調用，計算模塊返回處理結果信息後，界面模塊做出反饋。

十二、描述結對過程

• 在項目計劃和設計的階段，咱們採用了徹底的結對討論。討論前事先閱讀相同的材料，討論時針對算法問題提出各自的見解和修改意見。如此，咱們肯定了無環狀況下基於拓撲排序和動態規劃的最長路徑算法，對於有環狀況通過討論咱們認定爲np問題，明確使用暴力解法，優化也僅針對下降訪問成本進行。
• 在實現過程當中，咱們也充分討論了關於命令行參數要處理異常的狀況，然後才着手實現。實現過程當中算法的數據結構作過幾回修改，從一開始使用n*n臨接矩陣到使用臨界鏈表（錯誤實現，結構體傳值而非傳指針），到最後發現問題終於解決內存佔用不斷膨脹的問題。優化算法的過程當中咱們也細緻地針對性能分析結果和大測試樣本下的代碼覆蓋率進行一些分支必要性的討論，不斷優化。
  

1三、結對編程反思

• 結對編程優缺點

  • 正如課本所描述的，結對編程的靈魂在於不間斷的複審，不斷地交替領航員的位置維持高效率、高正確性的編程過程。
  • 基於這樣的分析，便能看到結對編程的條件：兩我的須要至少須要在工做任務上掌握的技能相同並水平接近，從而才能以同等的技術水平相互審查提醒。
  • 而不間斷互審也是有必定代價的，如兩我的須要進行充分的交流，想法上要同步，這是須要花費時間的；又若是兩我的並不很好地知足結對編程的條件，如技能覆蓋不一樣，則交流每每會變成單向的，互審的有效性每每也會變成單向有效。一樣地，有些狀況下，工做任務是能夠平行進行的，如測試程序的編寫和功能程序的編寫時能夠同時進行的，有些較複雜的類也是能夠同步開發的，因而結對編程實際上創建在同步開發的機會成本上。
  • 此外，實際踐行過程當中，咱們還發現結對編程一旦採用須要儘量全程採用。兩人在共同時間沒法調和的狀況下無可奈何進行的開發，再次結對時每每須要較長間相互說明並理解工做成果，若是遇到問題，則更麻煩，被說明的人每每被原先寫代碼的人的思路牽着走，較難像正常結對編程互審時保持本身獨立的思考，跳出思惟慣性而去發現錯誤。

• 我和搭檔的優缺點

  	本人	搭檔
  優勢1	熟悉c#，較熟悉vs2017	調試能力強
  優勢2	較熟悉框架、接口設計	對題目需求理解較細緻
  優勢3	待人友善，樂於溝通	待人友善，樂於溝通
  優勢4	能提出一些新的設計想法	能快速響應需求（設計）中的變化
  缺點	debug時不細緻，容易進入思惟慣性找不到問題	對vs較不熟悉

  • 總的來講，此次項目咱們嘗試告終對編程，但也有一些時間在進行各自開發。結對的時間裏有時會由於雙方對編程語言的熟悉程度不一樣有效率較低的狀況，但慢慢地隨着磨合的進行，結對工做的代碼複審效率大有提升。

1四、PSP表格回填

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

• 實際開發過程當中，用於學習、實踐算法的時間超過預期，其他時間較接近。

1五、模塊鬆耦合

• 按照做業接口要求封裝dll後，咱們和16091049 16061057互換了Core，咱們能正常使用對方的c++ dll,對方調用時卻不能看到函數接口問題，但我方自測dll時用c#調用能夠正常工做，可能與c++調用c#dll方式有必定關係。