| 項目 | 内容 |
|---|---|
| 這個作業屬于哪個課程 | 2021春季軟體工程（羅傑 任健） |
| 這個作業要求在哪裡 | 結對程式設計 |
| 我在這個課程的目标是 | 學習并掌握利用軟體工程的思想與方法建構大規模高品質的軟體系統的能力\團隊協作能力等 |
| 這個作業在哪個具體方面 幫助我實作目标 | 嘗試結對程式設計開發，合作,對PSP進行親身體驗 |
| Gitlab位址 | 學号後四位 |
|---|---|
| 3407 3075 |
結對程式設計有感
現場照片（設計階段）:
3075：
結對程式設計和個人程式設計之間最大的不同就是多了一個能随時和你讨論的人。在代碼設計的時候，兩個人之間互相的交流和讨論能夠極大地減少出現疏漏的情況，同時也能互相提出更好的措施來優化代碼的設計。比如這次在設計目錄結構的時候，利用hashmap來存儲所有的子檔案和子目錄就是yzm想出來的。同時在後續的編寫測試階段，從他人的視角上能夠發現很多自身難以發現的盲點，包括一些拼寫上的錯誤，邏輯上的錯誤等，這些都是自己走查很難發現的。總之，可能由于是第一次參與結對程式設計，彼此間互動的效率可能不太滿意，但是結對程式設計能夠讓人在寫寫代碼的時候多一份思路，多一種視角，這能夠很好地拓寬程式設計者的思路并提高代碼的品質。
3407：
嚴格意義上的結對程式設計應該是兩個程式員共用一台機器, 一個做“領航員”, 一個做“駕駛員”. 從這個角度看, 我們這一次的結對程式設計經曆不那麼“正宗”. 在設計階段我們坐在一起邊設計邊讨論, 但在編碼和測試階段, 我們則是遠端分工合作, 而且由于未提前協商, 我們編碼和測試的進度并不是一緻的,是以在前期有“結對程式設計”的在後期更像是“組隊程式設計”. 前期設計的時候,我認為兩個人的結對,對項目的設計是非常有利的: 兩個人邊設計邊讨論, 在互相糾錯和啟發下設計的進展會很快, 而且我發現兩人結對, 專注力明顯提升,思維也活躍起來…….總的來說我們的工作推進得不錯, 由于雙方積極幹活,任務完成得比較順利.
事後反思發現,我們結對程式設計的工作效率不高, 互相配合還不夠, 同時存在一定的溝通成本…….具體來說, 我認為有兩大原因: 設計階段雙方都忘記使用UML圖進行溝通, 這造成雙方因擔心編碼風格不一緻而采取分工合作先編碼後測試的政策; 單元測試與編碼未同步進行, 基本上編碼,代碼稽核, 測試,是流水線作業,而非并行.
另外結對程式設計第一階段, 在合作開發的過程中, 我一定程度上充當了測試員的角色, 發現代碼稽核和單元測試的重要性, 與其他人交流的過程中發現在代碼風格, UML設計這塊有所欠缺，這都曾是我在OO課程中不以為意的地方．
在結對程式設計的過程中,我好像對自我有了新的認識—— 自身特點: 謹慎細心,在局部問題考慮周全, 這就造成了我設計時挺适合做補充,測試時做白盒測試能查出不少bug ; 思路相對不靈活,反應不快, 此次認識到技術方面需要加強學習的地方: UML設計, 代碼風格(代碼接口設計, 注釋等) , 工具的使用與配置檔案（CI, maven的使用);
設計和實作思路
對于檔案和目錄類以及結構
本次項目中最基礎的就是對于檔案類和目錄類以及其結構的設計，考慮到檔案和目錄有很多相同的屬性，并且一個目錄下同時會有子檔案和子目錄，于是我們便設計一個檔案和目錄的父類：
public class FileOrDir {
private String name; //名稱
private int size; //大小
private String absoluteRoot; //絕對路徑
private int createTime; //建立時間
private int modifyTime; //最後一次修改時間
private Directory father; //父目錄
} 檔案和目錄分别繼承這個父類，并且在檔案中增加“content”内容屬性，在目錄中增加“child”屬性用來記錄該目錄下的子檔案和子目錄，這樣檔案類和目錄類就設計好了
同時在檔案的存儲上，我們考慮采用的是樹形結構，再加上由于每個檔案的絕對路徑是唯一的，便利用HashMap來儲存目錄的子檔案和子目錄來提高查找時的效率
private Map<String, FileOrDir> child; //目錄的内容，包括子目錄和檔案 key：檔案名 關于路徑
路徑的查找實際上是對于字元串解析工作，很自然的便想到用split方法将輸入的路徑名稱按照"/"分割，然後從起始目錄開始一層一層往下查找。
一開始考慮到由于每一個方法在路徑搜尋的過程中的處理都會有一些不同，是以一開始沒有打算為路徑搜尋抽象出一個方法，而是每個方法内部自行解決。後來發現這樣寫出來之後代碼過于備援，又考慮到不管是檔案路徑還是目錄路徑，除了路徑的最後一項之外對于前面的部分處理方法是相同的，于是便寫了一個findDirectory方法，用于找到給出路徑的倒數第二個目錄（例如 "a/b/c" 就找到b），之後的處理就因哥函數而異了。
同時需要注意的是，如果在路徑的最後出現.或者..的情況，各函數需要特别注意處理。在後續的debug環節中在這上面栽了不少跟頭。
關于各種方法
不管是檔案操作方法還是目錄操作方法都是基于路徑的，是以基本上所有方法第一步都是搜尋，然後根據搜尋的結果來進行各種操作。需要時刻注意的是，該方法進行的操作是否會修改檔案的修改時間，目錄的修改時間，檔案或者目錄的大小。這些我們都同方法實作的基本邏輯一起在方法設計的時候提前梳理了一邊并寫在了方法前的注釋裡，防止出現遺漏。
我們感覺本次作業中最複雜的一個方法就是遞歸建立目錄的makeDirectoryRecursively方法。原因是因為他和其他所有方法的在路徑搜尋上的邏輯都不同，不能調用上面設計的findDirectory方法。再加上該方法需要考慮的特殊情況比較多，例如路徑中出現../..，末尾出現.或者..之類的神奇情況，導緻對于該方法的程式設計與調試花費了大量的時間。最後發現這個方法的邏輯其實也很簡單，每一層搜尋，如果找到就進入，找不到就建立。
這裡要感謝一下提問區某同學給出的一個想法，幫助我們很好的了解了.和..的意義：在一個目錄建立時，預設該目錄下已有兩個子目錄，分别是指向自身的.和指向上層目錄的..。在這個想法的基礎上，很多一開始考慮的特殊情況也就沒有那麼難處理了。
PSP
| PSP2.1 | Personal Software Process Stages | 預估耗時 | 實際耗時 |
|---|---|---|---|
| Planning | 計劃 | 10min | |
| · Estimate | · 估計這個任務需要多少時間 | ||
| Development | 開發 | 18h | 17h30min |
| · Analysis | · 需求分析 (包括學習新技術) | 1h | |
| · Design Spec | · 生成設計文檔 | 1h30min | |
| · Design Review | · 設計複審 (和同僚稽核設計文檔) | 30min | 15min |
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | ||
| · Coding | · 具體編碼 | 6h | 5h |
| · Code Review | · 代碼複審 | 2h | 4h |
| · Test | · 測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | 2h50min | 4h20min |
| · Test Report | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | 20min | |
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | ||
| 合計 | 21h | 22h |