結對項目第Ⅲ階段
| 項目 | 內容 |
|---|---|
| 教學班級 | 2021春季軟件工程（羅傑 任健） (北京航空航天大學 - 計算機學院) |
| GitLab項目地址 | 2021_Xiaodong_Lu-Pengyang_Xie_pair_work |
| Mokoghost學號后四位 | 3647 |
| duckingss學號后四位 | 3054 |
結對項目實踐反思
問題分析
針對前面兩個階段中出現的問題，分析問題的特征、產生的根源和對質量的影響程度；
第一次出現的問題
- 討論時間過長
第一次結伴作業中，在分析規划方面，我們花費了一個下午和晚上的時間來進行需求分析，代碼結構設計，在分析規划階段就實現了MyFileSystem內部函數的邏輯，在編碼階段就只需要實現File，Dir還有Parser類內部接口即可，編碼實現階段異常順利，然而這樣的壞處在於效率不高，整個開發階段並行部分很少，大部分時間是串行，而且在規划階段就將FileSystem類內部的具體邏輯實現也沒有必要。不過充分的討論讓我們避免了低級錯誤和結構問題，提升了我們的代碼質量。
第二次出現的問題
- 討論不夠充分
事先沒有充分分析指導書，對於很多細節的實現沒有仔細思考充分討論交換意見，甚至導致后期出現需要對結構進行一定規模修改的bug。同時，由於討論不充分，分工后開發用戶系統的同學也無法幫助開發文件系統的同學修補bug或是提供思路，對其實現細節不清楚，編寫單元測試時只能黑盒測試。這嚴重影響了程序質量，造成了大量Debug的時間和對指導書的誤解。例如，對於異常拋出的處理，未經詳細的討論定下實現的方式，造成編寫此部分的同學誤入歧途，構想了許多非必要的簡化，實則為后期引入了很多麻煩。
- 出現問題時沒有及時尋求幫助
每當產生對指導書的疑問時，總是自顧自地推理，試圖通過一己之力解決疑問，浪費了大量時間用於討論需求與規則。
需求分析收獲
總結結對項目中的需求分析實踐體會，並分析哪些bug是因為需求分析不足而帶來的；
在本次結伴編程中，我們兩次任務對需求分析占比不同，導致了完全不同的結果。第一次細致的需求讓我們在編碼階段如魚得水，第二階段不細致需求分析則讓我們在編碼和測試階段痛苦萬分，特別是由於沒有討論清楚mv，cp的不同復制，修改行為，異常拋出如何設定，軟硬鏈接在重定向問題，我們在這幾個函數上花費了大量的時間，屬於鄒欣老師書上說的寫了再改的模式，花費了我們大量的時間成本。
綜合兩次經驗，我們總結出需求分析的幾個經驗。需求分析需要捋清楚具體的行為，在接口固定的情況下，對於復雜函數可以通過嘗試先編寫單元測試的方式進行需求分析。同時，我們認為需求分析中需要和架構設計應該是能夠耦合在一起的(至少對於本次作業而言)，因為需求文檔中各個看似無關的需求可以映射到某一個架構上，例如本次的軟硬鏈接中，如果在需求階段把軟鏈接看作指向索引的索引(即，存儲的是字符串)，硬鏈接看作指向文件的索引，那么在討論重定向的問題時就會輕松很多。
架構設計體會
總結結對中的架構設計實踐體會，描述通過改進設計來提高程序的性能改進的思路和方法，並分析哪些bug是因為架構設計不足（特別的，需求變化）而觸發的bug；
完成第一次作業時充分的討論讓我們整體的架構魯棒性較好，第二次作業時由於某些函數進行了"寫了改"的模式，文件系統架構有些不足，由於把把本該在FileSystem級處理的函數，放入了Dir類中，導致了cp和mv的許多bug。
兩次設計中，在架構設計方面，我們對於軟件設計中的設計原則有了更加深刻的理解。特別是職責單一原則。在提高程序魯棒性方面，我們通過在不同的類中實現不同方法的方式，來講錯誤進行了局部化，同時編碼復雜度也得到了指數級下降。對於程序優化方面，由於涉及到全局優化，我們通過人工分析位於某一層級的方法中的共有模式，將他們提取處理出來到一個函數內，再對該函數進行優化。比如對於filewrite,filetouch,fileappen都有同樣的檢查存在->不存在->創建的模式，我們寫了一個filemodifyMode函數,並對這個函數邏輯進行部分優化。對於架構的另外一個優化層面，則是優化底層函數，比如各個類內部實現的find函數，對其進行一些細節上的修改進行優化，或者在共同父類中進行優化（在父類中優化為設想，沒有實際實現）。
進度、質量和溝通管理實踐體會
總結結對過程中的進度、質量和溝通管理實踐體會，並分析哪些bug是因為兩個人的理解不一致而導致；
實際上，在本次結對作業中我們對項目進度、質量和溝通的管理是缺失的。由於不重視管理中的規范，我們沒有記錄開發流程，大部分問題與討論也僅停留在口頭，過程中產生的log文件往往只有寫它的人才能看懂，並沒有什么規范（實際上做的最好的規范是Javadoc，我們在方法前書寫了數百行Javadoc，為我們的開發、code review都提高了效率）。
對於進度的把控十分崩壞，沒有明確每一次開發的目標，這導致了多次意義不明的熬夜，時常陷入低效的漩渦，一個人埋頭開發，另一個人卻處理着並不要緊的工作（例如寫測試，完全可以不熬夜完成）。
代碼質量的把控在明確的code style下看似能夠輕易地落實，實際上缺乏溝通使得一些地方編程思路不一致，同時缺乏統一的規則與詳實的記錄，讓不同時間的不同開發者難以統一。
缺乏溝通也降低了本次開發的效率，很多時候同伴的“失聯”讓另一位開發者不知所措。沒有經過充分的獨立思考時常也會造成低效的溝通，問出“奇怪的問題”，實際上可能答案就蘊藏在指導書中，卻要讓負責另一部分的同伴花費幾分鍾尋找解答。
結對項目建議
提出建議：根據三個階段的結對項目的實踐經驗，對如何更好的實施和管理結對項目提出自己的建議。
- 充分的討論
無論是分析需求、明確規則、討論架構，還是確定分工、分配時間、划分成果，充分交換意見都是合作項目的必須，沒有達成一致的意見，無法擁有良好的結對體驗。
- 明確規則
開發中的不一致幾乎都是由於缺乏統一的規則。結對項目的代碼風格，設計流程，程序架構、分工配合以及時間安排，都應該在開始時定義好。
- 詳實而易讀的記錄
開發過程中看不懂之前寫的或是別人寫的代碼實在是一件很痛苦的事。之前修改了哪些、為什么修改，討論好的設計架構、實現方式，對需求的解讀等等，這些全部應該詳細地記錄下來，同時需要讓雙方都能讀懂不產生歧義，雖然在記錄時可能消耗時間，但是在開發過程中一定能提高效率，降低代碼復審的難度。
- 清晰的目標
沒有清晰的目標可能會導致無意義的熬夜，也可能會導致低效的開發、單純浪費時間。確定每天要實現的內容，明確要達到的目標可以幫助開發者心里有數，避免開發時的迷茫。
PSP 規划
整個項目的總PSP：
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 25 | ~25 |
| · Estimate | · 估計這個任務需要多少時間 | 25 | ~25 |
| Development | 開發 | 1360+890+90 | 2190+1205+90 |
| · Analysis | · 需求分析 (包括學習新技術) | 300+240+10 | 180+180+10 |
| · Design Spec | · 生成設計文檔 | 30+30+5 | 0+30+5 |
| · Design Review | · 設計復審 (和同事審核設計文檔) | 10+10+15 | 120+5+15 |
| · Coding Standard | · 代碼規范 (為目前的開發制定合適的規范) | 10+10 | 10+30 |
| · Design | · 具體設計 | 300+60 | 480+320 |
| · Coding | · 具體編碼 | 500+360+40 | 600+460+40 |
| · Code Review | · 代碼復審 | 60+60+10 | 60+10 |
| · Test | · 測試（自我測試，修改代碼，提交修改） | 180+120+10 | 740+180+10 |
| Reporting | 報告 | 120+60+30 | 150+90+30 |
| · Test Report | · 測試報告 | 30+30+10 | 60+30+10 |
| · Size Measurement | · 計算工作量 | 30+20+10 | 30+30+10 |
| · Postmortem & Process Improvement Plan | · 事后總結, 並提出過程改進計划 | 60+30+10 | 60+30+10 |
| 合計 | 1490+960+130=2580 | 2350+1305+130=3785 |
CI體驗感想
通過這次結對編程，你對CI的使用體驗如何？你對這一工具有何認識？
這兩次作業中，我們使用CI進行了自動化評測，自動JUnit測試和測試覆蓋率導出。我覺得CI是一個非常符合工程思維的東西，他將打包測試等流程進行了自動化。一次配置，就將團第成員從某些每次都要進行的繁瑣流程中解放了出來，是一種一勞永逸的方式。然而本次CI使用還是有些不足，每次使用的單元測試時都需要進行包的安裝，花費了許多時間，如果以后將自己的將runner換成自己的服務器，體驗會有進一部提升。
結對編程感想
描述你們結對的方法、結對過程中遇到的困難與收獲，結合自己的結對經歷，說明結對編程的優點和缺點，分享可以推廣的結對妙招。
結對過程中，我們配合默契，討論充分，對於同一問題產生不同的看法總是能通過“橋梁”或是“說服”的方式達成一致，期間有思考，有探討，有妥協也有對對方奇思妙想的贊嘆。
結對編程增強了我們的工程能力，尤其是項目合作的能力，同時有效提升了代碼質量，兩個人總能考慮地更周全，有頭腦風暴思路也產生地更快。
然而結對編程對項目的質量管理、成員的溝通能力都有更高的要求，相對於一個人寫代碼安靜的環境，溝通可能會對對方產生干擾。同時，如果沒有充分的磨合，時間開銷可能反而比一個人開發更大，觀察發現，班級里許多編碼時間比我們更短的項目，開發任務往往在由一個人承擔。
評價你的隊友，使用漢堡點評法評價你的結對伙伴，務必給TA 提改進意見。
Mokoghost➡️duckingss：
duckingss的碼力和動手能力很強，一邊討論一邊就能開始寫，我實在佩服👍🏻。參與過OI和ACM的duckingss知識面也十分廣，不僅對於自己未來的目標明確，而且已經實實在在地走出了堅實的步伐，是一個實干家！大行不顧細謹，duckingss有時候會疏忽一些細節，例如代碼規范、代碼結構，有些競賽畫風，不過經過我的一兩次建議后就立馬能寫出工整而規范的高水平代碼，其謙虛、細致、及時采納他人意見如此，不可不謂之有才。
duckingss➡️Mokoghost：
Mokoghost的思維條例非常清晰，能夠把很多例如軟硬鏈接結構的復雜的問題考慮清楚，有豐富的管理和科研經驗，也非常具有團隊合作精神,能夠及時切換團隊身份，進行救火。但是作息安排可能有點不太健康，希望能好好注意一下，有一個健康的身體才能走得更遠，才能更好地展現Mokoghost的才華。
描述在本次結對編程的過程中，你們使用了哪些軟件工具，是如何應用於實踐的。
本次結伴中我們使用了IDEA+code with me，git，maven+cobertura三款軟件工具。IDEA+code with me用於在線和遠程協同開發。git用於版本管理，記錄每次提交信息等功能，我們通過git的log來進行復盤。通過使用maven+cobertura進行測試單元測試，引入依賴包。
描述通過本次結對編程的感悟和體會，對本次作業的有哪些想吐槽的，覺得本次結對作業內容可以在哪些方面做出改進？
詳見結對項目第一階段總結與對軟工課程的拙見的正文與評論區。