注：納斯納斯是阿拉伯傳說裡的半邊人，匈古夫同理。标題暗示結對程式設計中兩個人都發揮對等的作用且不可或缺，并且對一個事物的兩種說法暗示了結對程式設計中兩人需要通過溝通來确認彼此對同一個事物的看法。
| 項目 | 内容 |
|---|---|
| 這個作業屬于哪個課程 | 2021春季軟體工程（羅傑 任健） |
| 這個作業的要求在哪裡 | 作業要求 |
| GitLab項目位址 | 2021_Ziming_Yang-Jingwen_Tian_pair_work |
| 學号後四位 | 3080 3420 |
| 我在這個課程的目标是 | 積累軟體開發經驗，提高工程能力 |
| 這個作業在哪個具體方面幫助我實作目标 | 體驗結對程式設計，培養集體意識，提高開發能力 |
一、結對程式設計感受
這次，我們繼續沿用第一次結對程式設計所使用的騰訊會議工具，因為它可以實作無障礙的語音交流與螢幕共享，個人感覺比兩個人湊在一起看一台電腦能夠達到更好的交流效果。以下是結對程式設計期間的截圖
FROM TIAN
在本次結對程式設計的過程中，我們對于整個過程更加得心應手，在git同步、程式設計的交流上不需要像第一次那樣花費許多時間，兩個人的溝通品質也得到了更進一步的提高，比如第一次我還經常在思考”他為什麼要這麼寫，這和我的習慣不一樣“，進而忽略了代碼正确率以及設計品質等更深一步的東西，但是第二次，我們已經可以在大部分跳過了解這步，直接進行設計上的溝通。
同樣的，在對于結對程式設計的作用上，我也有了更進一層的真實體驗。第一次的時候還會抱着“這個東西這麼簡單，就是麻煩了一點點，我自己也可以寫的”想法，但是到了第二次，整個的體系雖然并不沒有複雜多少，但是各種細節的處理上卻是彎彎繞繞、令人頭疼，所存在的問題也永遠比發現的多，這也導緻了我們花費大量的時間在測試上。這個時候，更能展現兩個人結對的好處。對于所有問題的解決，都是經過我們共同讨論後的結果，這樣明顯能比一個人所考慮得更加全面，同時在讨論的過程中，也能進一步提高修改的正确性以及必要性。
FROM YANG
本次結對程式設計相比于上次的體驗式，更接近于壓力式（盡管這個壓力式可能是指導書的全面性的缺失而導緻的）。盡管本次指導書的内容較上次指導書内容較少且使用者系統部分較簡單，但是軟、硬連結的出現，讓目錄樹變成了目錄圖，mv和cp方法的出現，目錄和檔案在目錄樹中的位置不再是靜态的了。這使得本次項目的邊界情況多的令人發指，再加上“不再贅述”所導緻的不能單純看某指令的對應内容來編寫該指令的代碼，使得我在結對程式設計的過程中逐漸煩躁，且思路愈發混亂。好在有領航員及時幫我梳理思路，才不至于陷入泥淖無法自拔。
除了上面所說的感受，這次我們對結對程式設計的整體流程更加熟練，溝通效率更高，建構了了“1看指導書->2實作指令->3發現問題->4提出 issue->5解決問題->1”的 pipeline，實作了端到端的閉環流程。
二、設計實作思路
在完成本次的檔案管理系統的增量開發前，我們首先對上次的設計進行了修改。一是異常抛出的位置，我們重新規定隻能在
MyFileSystem
和
Parser
的方法中抛出異常，這樣的規定能使我們的編碼邏輯更加清楚，在調試的時候也不會出現忘記抛沒抛出異常、在哪抛出異常的問題。二是我們重寫了
Parser
中的方法，更加确定了它作為解析類的作用，使其隻完成解析工作且盡量解析完全。三是為了提高時間效率，我們将原來的先擷取檔案對象、後擷取其上級目錄對象的邏輯，改為先擷取其上級目錄對象，然後根據其目錄對象直接在目錄樹中擷取此檔案對象。
對于本次的增量設計，我們了延續了上次的架構和思路，建立新的硬連結檔案
HardLinkEntry
類和軟連接配接檔案
SoftLinkEntry
類，仍使
FileSysEntry
類來作為目錄類和所有檔案類的父類，同時，考慮到新增要求，在其中添加統一屬性（user_name、group_name、count），并使檔案類的
getCount
方法恒傳回1。
對于硬連結和軟連結的設計，我們采用”硬連結連結到檔案，軟連結連結到路徑“的思想，分别在硬連結中存儲所連結到的檔案對象，在軟連結中存儲所連結到的絕對路徑。對于它們的重定向操作，我們選擇建立一個
Redirectable
接口，使
SoftLinkEntry
HardLinkEntry
均需實作此接口的
redirect()
方法。
此部分的UML圖如下
對于
redirect()
方法的實作，在硬連結中，直接傳回其所連結到的檔案對象；在軟連結中，使用
FileSysEntry
的
find
方法根據其連結到的絕對路徑在目錄樹中找到其對應的檔案/目錄，同時，為了在
FileSysEntry
中通路目錄樹，我們将
MyFileSystem
中存儲的根目錄設為公共靜态變量。
同時，由于硬連結的
size
實際存在，而
fwrite
fappend
會更改檔案的大小，此時也應該通知連結到其的硬連結的上層目錄更新
size
，考慮到硬連結與檔案多對一的關系，我們在檔案類中新增
hardLinks
清單，存儲所有連結到其的硬連結，并在檔案大小更新時通知清單中所有的硬連結。
對于使用者系統的實作，我們建立了使用者
User
類和使用者組
Group
類，分别在使用者群組類中設定公開靜态
root
對象，代表最初存在的root使用者和其存在的主組。對于使用者群組之間的多對多的關系，我們分别在
User
類中存儲其所在的
groups
清單，在
Group
類中存儲其包含的
users
清單，便于通路查詢。
在
MyUserSystem
類中，我們設定了
groups
清單存儲所有的已建組，同時，為了便于使用者的查詢，我們同樣在其中存儲了所有使用者的
users
清單。
對于使用者系統和檔案系統的互動，我們參考了issue區中所提供的方法（【讨論】使用者系統和檔案系統如何互動），利用單例模式，建立一個單例類
Manager
，在其中設定
myFileSystem
myUserSystem
屬性，在檔案系統和使用者系統的構造方法中分别為其指派，這樣，我們就能夠通過
SystemManager
在兩個類中互相擷取其方法/屬性。同時，考慮到指令數變量的公有性，我們将其的位置也由
FileSystem
改到了
SystemManager
中，便于兩個系統的調用。
這樣，對于
exit
指令中的擷取上一次
su
指令時使用者所在的工作目錄需求，我們就可以在進行
su
操作時通過
SystemManager
中的
myFilesystem
擷取目前工作目錄的絕對路徑，進行存儲，并在執行
exit
指令時，更新
myFileSystem
中的目前工作目錄。
同樣的，對于檔案系統中建立檔案/目錄時，需要的目前使用者和其所在使用者組的資訊，也可以通過
SystemManager
myUserSystem
獲得。
對于異常的設定，為了設計架構的清晰性、便于調試，我們将過程中可能出現的異常做了區分，并對第一次的異常情況進行了适當調整，最後區分為
MyFileSystemException
MyUserSystemException
，分别繼承課程組給出的異常抽象
FileSystemException
類和
UserSystemExceotion
類。
最終架構如下
三、PSP表格記錄
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 30 | |
| · Estimate | · 估計這個任務需要多少時間 | ||
| Development | 開發 | 770 | 1250 |
| · Analysis | · 需求分析 (包括學習新技術) | 20 | |
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計複審 (和同僚稽核設計文檔) | 50 | 60 |
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 120 | |
| · Coding | · 具體編碼 | 360 | |
| · Code Review | · 代碼複審 | 90 | |
| · Test | · 測試（自我測試，修改代碼，送出修改） | 180 | 570 |
| Reporting | 報告 | 110 | |
| · Test Report | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | ||
| 合計 | 890 | 1390 |