标題含義：納斯納斯是阿拉伯傳說裡的半邊人，匈古夫同理。标題暗示結對程式設計中兩個人都發揮對等的作用且不可或缺，并且對一個事物的兩種說法暗示了結對程式設計中兩人需要通過溝通來确認彼此對同一個事物的看法。
| 項目 | 内容 |
|---|---|
| 這個作業屬于哪個課程 | 2021春季軟體工程（羅傑 任健） |
| 這個作業的要求在哪裡 | 作業要求 |
| GitLab項目位址 | 2021_Ziming_Yang-Jingwen_Tian_pair_work |
| 學号後四位 | 3080 3420 |
| 我在這個課程的目标是 | 積累軟體開發經驗，提高工程能力 |
| 這個作業在哪個具體方面幫助我實作目标 | 體驗結對程式設計，培養集體意識，提高開發能力 |
一、結對程式設計感受
本次結對程式設計使用騰訊會議工具，進行語音交流與螢幕共享，完成項目設計、編碼、測試以及複審過程。在開始時，嘗試使用了 IDEA 的 code with me 插件，發現由于網絡原因，導緻以 YANG 作為 User1，TIAN 作為 User2 時雖然可以使用插件功能，但同步效果較差，二者角色對調時，由于配置因素，無法正常使用該插件，遂放棄。
FROM TIAN
在結對程式設計的過程中，通過觀察對方的設計思路、編碼方法，與自己的想法進行對比，能夠體會到自己的不足，學習到對方好的編碼習慣、架構特點，也能夠及時從不同角度指出對方設計中可能存在的問題，使設計架構更完整、代碼品質更高。同時，這種直接觀看對方設計、編碼，與對方直接交流問題的過程，能夠更加清晰地體會到一些老師課上所講的問題，比如減少耦合性、各部分設計獨立完整等，達到一種互促學習的效果。雖然兩個人一起進度有點慢，因為彼此思路不相通，經常需要互相講解，但是這個過程也可以提高代碼品質，很大程度上減少了debug的時間。
FROM YANG
本次的結對程式設計是一次很有趣的實踐。雖然我們選擇了以騰訊會議的形式進行，沒有做到完全的同一台電腦前程式設計，但是實踐過程中仍然保持了“駕駛員”和“領航員”身份的及時切換。在設計前，我們首先對彼此的編碼習慣進行了溝通，最後標明了以OO時的編碼規範為基礎，對部分嚴格要求進行可容忍的放松，使得之後的程式設計過程中沒有出現因編碼習慣不和而進行大幅修改的情況。在設計和程式設計過程中，我們貫徹了交流至上的理念，在發現問題或者有想不明白的地方時，及時發問、讨論交流。對于“領航員”來說，這不僅發現了代碼的問題，也是對自己的一種檢定：自己程式設計時是否也會出現類似問題；而對于“駕駛員”來說，講述自己編碼時的思路可以視為小黃鴨debug法的更高階實踐，是對自己編碼的全面梳理。而且在最後的單元測試編寫過程中，雙方可以同時編寫單元測試，提高了效率。
但是誠如“過早的優化是萬惡之源”所言，結對程式設計作為靈活開發的一種實踐模式，追求對代碼不間斷的複審。然而由于我們本身所具有的局限性，對于提出的問題，往往隻能給出一個更新檔式的修改，使得某些方法在最後已經陷入了不得不重構而重構又涉及者衆的兩難境地。
是以結對程式設計好嗎？好，這種方式确實能讓我們提高代碼品質，并且互相學習。
那麼結對程式設計是萬靈藥嗎？不盡然。如果以從結對程式設計中學習為目的，它顯然利大于弊，能有一個人随時從另一視角切入顯然是一種有益的補充。而如果以更好的工程品質為目的，它的利弊就需要權衡，如果兩人的架構能力都比較有限，在“領航員”提出問題時，“駕駛員”就容易一葉障目，僅僅局限于自己剛寫的幾行代碼進行修改，而忽略了bug背後的設計問題。這部分問題的解決有賴于更深入的思考，在結對程式設計這種及時性強的環境中不容易做到。
二、設計實作思路
本次檔案管理系統的實作中，我們設計了一個
FileSysEntry
類來作為目錄類和檔案類的父類，使得二者能夠更好地統一在一個資料結構中，實作一些統一的屬性
（name、abspath、create_time、modify_time、size）
和
get、set、info
方法等。
基于檔案和目錄都具有的
info
操作，我們設計了一個
Infoable
接口，具有
info
方法，傳回要求中的
info
資訊，同時使
FileSysEntry
實作這個接口。（本意是使用基于接口的程式設計方法，但是在編碼完成後，由于繼承的實作，發現
info
方法并不具有獨立設定接口的特殊性，故最終取消了
Infoable
接口）
對于整個檔案系統，我們設定它具有根目錄和目前目錄屬性。
對于檔案結構的存儲，我們選擇在目錄類中設定
Treemap
屬性，以檔案/目錄名為鍵值，使它能夠按名稱字典序有序地存儲子目錄或檔案（友善
list
操作），在查找檔案時，可根據路徑逐層向下查找擷取檔案對象。
對于路徑的解析相關操作，我們設計了一個
Parser
類，實作解析路徑、上層目錄、檔案名，判斷是否為絕對路徑，拼接路徑等靜态功能性方法。
為了設計架構的清晰性、便于調試，我們将過程中可能出現的異常做了區分，并均繼承課程組給出的異常抽象
FileSystemException
類。
最終架構如下
三、PSP表格記錄
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 30 | 20 |
| · Estimate | · 估計這個任務需要多少時間 | ||
| Development | 開發 | 770 | 1070 |
| · Analysis | · 需求分析 (包括學習新技術) | 40 | |
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計複審 (和同僚稽核設計文檔) | 50 | |
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | 10 | |
| · Design | · 具體設計 | 60 | |
| · Coding | · 具體編碼 | 360 | 600 |
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | 150 | 240 |
| Reporting | 報告 | 105 | 90 |
| · Test Report | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | 45 | |
| 合計 | 905 | 1180 |