標題含義：納斯納斯是阿拉伯傳說里的半邊人，匈古夫同理。標題暗示結對編程中兩個人都發揮對等的作用且不可或缺，並且對一個事物的兩種說法暗示了結對編程中兩人需要通過溝通來確認彼此對同一個事物的看法。
| 項目 | 內容 |
|---|---|
| 這個作業屬於哪個課程 | 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 | · 估計這個任務需要多少時間 | 30 | 20 |
| Development | 開發 | 770 | 1070 |
| · Analysis | · 需求分析 (包括學習新技術) | 40 | 20 |
| · Design Spec | · 生成設計文檔 | 40 | 40 |
| · Design Review | · 設計復審 (和同事審核設計文檔) | 50 | 40 |
| · Coding Standard | · 代碼規范 (為目前的開發制定合適的規范) | 10 | 10 |
| · Design | · 具體設計 | 60 | 60 |
| · Coding | · 具體編碼 | 360 | 600 |
| · Code Review | · 代碼復審 | 60 | 60 |
| · Test | · 測試（自我測試，修改代碼，提交修改） | 150 | 240 |
| Reporting | 報告 | 105 | 90 |
| · Test Report | · 測試報告 | 30 | 30 |
| · Size Measurement | · 計算工作量 | 30 | 20 |
| · Postmortem & Process Improvement Plan | · 事后總結, 並提出過程改進計划 | 45 | 40 |
| 合計 | 905 | 1180 |