專案	內容
課程班級部落格連結	2022年春軟體工程課程班（2019級電腦科學與技術）
這個作業要求連結	實驗三 軟體工程結對專案
本次課程學習目標	1.體驗軟體專案開發中的兩人合作，練習結對程式設計（Pair programming）。 2.掌握Github協作開發軟體的操作方法。
這個作業在哪些方面幫助我實現學習目標	1. 利用git第一次實現了協作開發，感覺不錯 2. 結對程式設計，完成了更多的內容 3. 對自己的程式碼規範有了更多的啟發和反省
結對方學號-姓名	201971010259-張圓圓
結對方本次部落格作業連結	201971010259-張圓圓 實驗三 結對專案—《{0-1}KP 例項資料集演算法實驗平臺》專案報告
本專案Github的倉庫連結地址	Knapsack-0-1

一、任務1 閱讀《現代軟體工程—構建之法》第3-4章內容

第三章 軟體工程師的成長

1. 軟體工程師如何成長？

• 積累軟體開發相關知識
• 積累問題領域的知識和經驗
• 對通用的軟體設計思想和軟體工程思想的理解。
• 提升職業技能
• 實際成果

2. 軟體開發的工作量和質量怎麼衡量？

• 專案/任務有多大
• 花了多長時間
• 質量如何
• 是否按時交付

3. TSP對團隊成員的要求：

• 交流
• 說到做到
• 接受團隊賦予的角色並按角色要求工作
• 全力投入團隊的活動
• 按照團隊流程的要求工作
• 做好準備工作
• 理性的工作

4. 軟體工程師的思維誤區：

• 分析麻痺
• 不分主次，相解決所有的依賴問題
• 過早優化，無視這個模組對全域性的重要性
• 過早擴大化/泛化
  解決大問題固然讓人感覺美妙，但是把小問題真正解決好，也不容易

第四章 兩人合作

1. 程式碼規範分為兩部分

• 程式碼風格規範
  • 程式碼風格的原則是：簡明、易讀、無二義性。Tab鍵在不同的情況下會顯示不同的長度，嚴重干擾閱讀體驗。

• 程式碼設計規範
  • 函式原則：只做一件事，並且要做好。

2. 程式碼複審的定義：看程式碼是否在程式碼規範的框架內正確地解決了問題。

二、任務2 兩兩自由結對，對結對方《實驗二 軟體工程個人專案》的專案成果進行評價

1. 結對方部落格連結：201971010259-張圓圓 實驗三 結對專案—《{0-1}KP 例項資料集演算法實驗平臺》專案報告
2. 結對方Github專案倉庫連結：Knapsack-0-1
3. 博文評價：
   部落格的結構很完整，每個部分都寫的很棒，是學習和借鑑的目標。內容充實，書寫認真，能從其中看出仔細認真的態度，是值得學習臨摹的一篇部落格。整個頁面美化也很到位，看起來豐富多彩，目錄的設定也使得跳轉觀看更方便。

• 博文結構：結構清晰完整，每個部分都寫得很清楚，把握了每個細節。
• 博文內容：從開始到結尾每一部分都完成了部落格要求。整個專案也實現了所有需求，程式碼結構完整，執行邏輯清楚。
• 博文結構與PSP中“任務內容”列的關係：部落格的內容幾乎與PSP內容對應。
• PSP中“計劃共完成需要的時間”與“實際完成需要的時間”兩列資料的差異化分析與原因探究：第一次做專案，對專案流程還不熟悉，不能對自己的時間做到合理把握，也不夠了解自己現在的能力導致時間規劃不夠準確。

4. 克隆結對方專案原始碼到本地機器，閱讀並測試執行程式碼

圖1 clone結對方實驗二專案 結對方實現了全部功能，完成度非常高。但是我們雙方使用的java編譯環境不同，導致專案克隆後，選擇用idea啟動對方的eclipse專案，無法正常編譯執行，於是選擇使用終端執行。

// 終端編譯執行
javac Main.java
java Main

圖2 idea執行eclipse專案

專案中動態規劃法輸出結果不正確。在執行過程中發現，由於編寫了絕對地址導致在編譯錯誤。在程式設計過程中應當減少絕對地址的使用以提高程式碼的可移植性。

String filePath = "D:\\2021-2022\\大三下\\軟體工程經濟\\Git\\0-1\\0-1-knapsack\\res\\beibao"+fileId+".in";

圖3 動態規劃法結果有誤

程式碼核查表

	專案	內容
概要部分	程式碼符合需求和規格說明麼？	是
	程式碼設計是否考慮周全？	是
	程式碼可讀性如何？	較好
	程式碼容易維護麼？	是
	程式碼的每一行都執行並檢查過了嗎？	是
設計規範部分	設計是否遵從已知的設計模式或專案中常用的模式？	是
	有沒有硬編碼或字串/數字等存在？	否
	程式碼有沒有依賴於某一平臺，是否會影響將來的移植？	依賴eclipse開發環境,無法在idea中執行
	開發者新寫的程式碼是否用已有的Library/SDK/Framework中的功能實現？在本專案中是否存在類似的功能可以通過呼叫而不用全部重新實現？	否
	有沒有無用的程式碼可以清除？	有很多重複性的程式碼
程式碼規範部分	修改的部分符合程式碼標準和風格麼？	符合
具體程式碼部分	有沒有對錯誤進行處理？對於呼叫的外部函式，是否檢查了返回值或處理了異常？	有
	引數傳遞有無錯誤，字串的長度是位元組的長度還是字元的長度，是從0開始計數還是從1開始計數	無錯誤，字元長度，從0開始計數
	邊界條件是如何處理的？switch語句和default分支是如何處理的？迴圈有沒有可能出現死迴圈？	沒有死迴圈
	有沒有使用斷言來保證我們認為不變的條件真的得到滿足？	沒有
	對資源的利用，是在哪裡申請，在哪裡釋放的？有無可能存在資源洩露？有沒有優化的空間？	有可能，存在優化空間
	資料結構中有沒有用不到的元素？	無
效能	程式碼的效能如何？最壞的情況是怎麼樣的？	是
	程式碼中，特別是迴圈中是否有明顯可優化的部分？	是
	對於系統和網路的呼叫是否會超時？如何處理？	是
可讀性	程式碼可讀性如何？有沒有足夠的註釋？	是
可測試效能	程式碼是否需要更新或建立新的單元測試？	是

5. 結對方專案倉庫中的Fork、Clone、Push、Pull request、Merge pull request日誌資料
   

圖4 倉庫fork記錄

三、任務3 採用兩人結對程式設計方式，設計開發一款{0-1}KP 例項資料集演算法實驗平臺

1. 散點圖繪製
2. {0-1}KP 例項資料集需儲存在資料庫

圖5 web頁面資料庫資料讀入
圖6 web頁面資料檢視

3. 人機互動介面要求為WEB頁面平臺可動態嵌入任何一個有效的{0-1}KP 例項求解演算法，並儲存演算法實驗日誌資料

圖7 web頁面揹包演算法選擇求解頁面
圖8 web頁面日誌檢視

4. 遺傳演算法求解{0-1}KP
5. 註冊頁面

圖9 app註冊頁面

PSP消耗時間

PSP2.1	任務內容	計劃共完成需要的時間(h)	實際完成需要的時間(h)
Planning	計劃	2	4
Estimate	估計這個任務需要多少時間，並規劃大致工作步驟	1	3
Development	開發	120(5天)	216(9天)
Analysis	需求分析（包括學習新技術）	3	10
Design Spec	生產設計文件	2	1.5
Design Review	設計複審（和同事稽核設計文件）	5	5
Coding Standard	程式碼規範（為目前的開發指定合適的規範）	0.5	0.58
Design	具體設計	2	2
Coding	具體編碼	72	96
Code Review	程式碼複審	40	5
Test	測試（自我測試，修改程式碼，提交修改）	12	15
Reporting	報告	3	6
Test Report	測試報告	1	1
Size Measurement	計算工作量	1	1
Postmortem & Process Improvement Plan	事後總結，並提出過程改進計劃	0.5	0.5

四、描述結對的過程，提供兩人在討論、細化和程式設計時的結對照片

圖10 github倉庫討論
圖11 互相詢問進度

五、專案倉庫

1. 多次commit的記錄

圖12 commit記錄

2. src資料夾

圖13 專案src資料夾

3. Github專案倉庫根目錄下專案程式碼規範文件

圖14 程式碼規範文件

六、小結

在上一次的專案設計中，結對雙方使用高階語言不同，且之前的學習方向不同，所掌握的程式設計技術不同。為實現“領航員”與“駕駛員”角色的輪流切換，商議決定專案設計包含兩部分：利用java語言實現app設計，利用Python語言實現html設計。其中app實現功能較為全面，但web頁面設計功能並不全面，且web在路由跳轉方面並沒有做到很好。在本次結對程式設計實驗中app顯示——駕駛員為張圓圓，web設計中——駕駛員為姜婷。角色切換過程中，互相學習，互相監督，提高專案效率、程式碼質量。
通過這次的互相結對對程式編寫的團體合作有了進一步的瞭解，熟悉了git在軟體開發中的作用。但是這次我覺得我沒能控制好個人情感，在結對開發過程中我對有些問題過於偏執，導致專案程序緩慢。之後我應該與隊員之間好好交流，互相理解，做好溝通。在結對過程中能感受到1+1>2，這是一次很好的學習機會！