| 項目 | 內容 |
|---|---|
| 作業所屬課程 | 2021春季計算機學院軟件工程(羅傑 任健) |
| 教學班級 | 周五上午 |
| 項目地址 | Gitlab地址 |
| 學號后四位 | 張書愷：3146 李巳辰：3464 |
結對項目實踐反思
問題分析-L同學
結對編程時出現的問題主要集中在第二階段，其主要特征為兩人的交流不夠深入。由於第二階段的任務量較大，會涉及到許多細節，時常出現兩人對需求的理解不同的情況。然而平時能夠抽出共同的空閑時間結對編程的時間又不多，當一個人的實現思路出現問題時另一個人也不能及時指出，這直接導致最終程序質量不高。這樣以來結對編程的優勢被弱化，因為兩個人相互交流而碰撞出的思路必然比一人獨自思考更全面。
需求分析實踐體會-L同學
需求分析是結對作業最重要的一環，因為其直接決定程序的架構設計。結對作業的需求主要來源於指導書和Issue。最開始應當通讀指導書，不能放過每一個細節，對容易忽略的或發生改變的需求最好另行記錄。同時這部分分析以兩人面對面進行最佳，因為這時的交流是最高效的。不過這往往無法完全解決需求分析的問題，在此之后每當遇到對需求的理解不清晰的情況時應當再細讀指導書或Issue、與伙伴交流等。
在第二階段的結對作業中，cp指令中需要覆蓋文件時，覆蓋后最終應當以dstName保存，而我們卻以srcName保存，還是因為在需求分析時沒有仔細考慮導致出現bug。
架構設計實踐體會-L同學
需求分析之后就要進行架構設計。架構設計時兩人的交流要最好有實質性的記錄，比如生成設計文檔或直接在代碼里設計接口和注釋，然后兩個人共同對架構設計進行審核。審核越謹慎，編程實現時走的彎路越少。此外，為了方便兩人對代碼的理解，代碼編寫前應當制定合適的代碼規范，比如分支對應的注釋、屬性要設置為private等。
第二階段要在第一階段的基礎上進行迭代，在修改架構時遇到兩個主要問題：文件系統和用戶系統之間的交互；軟硬鏈接帶來的路徑尋址問題。前者我們新建一個交互類並采用單例模式用於兩個系統之間的信息交換；后者我們利用遞歸對路徑進行解析並返回對應文件或目錄類的引用。不過由於各個指令的要求不同，比如有的要求路徑末尾是文件，不能有/，而有的既可以是文件也可以是目錄，我們在遞歸時沒有充分考慮不同指令的需求，導致程序沒有正確拋出異常。現在想來，我們在架構設計時過於倉促，對實體的抽象程度還不夠，也沒有充分利用多態等面向對象的特性，使得最終的架構不夠清晰，還有待改進。
結對過程實踐體會-L同學
結對過程中的交流與工作的進度與質量直接掛鈎，第二階段工作的復雜性讓我們充分意識到這一點。我們由於中途溝通的失誤，工作的進度較慢，最終也是壓線提交，同時質量也存在問題。當壓力巨大時，任何一方都不能失去耐心，要保證平穩的心態，冷靜分析當前的問題。第二階段的代碼編寫過程中我們有一次由於溝通不到位，在一個晚上的結對后沒有什么實質性的成果，同時又因為臨近DDL，雙方搞得都不愉快。不過在回到寢室后我們各自都認真了反思，在簡短的溝通后各自集中尋找問題解決，最終加班加點完成了任務。
此外在具體編碼之后，代碼的復審和測試也是一項必不可少的工作。復審可以檢查代碼規范、清除無用代碼；做好測試不僅有利於對各種分支進行覆蓋，還有利於進行回歸測試，良好的測試能初步保證代碼的質量。不過這也是一項繁重的工作，需要兩個人配合着進行。
結對項目建議-L同學
-
版本管理：版本管理自然使用Git，不過建議兩人同時對代碼進行編輯時，編輯部分不要相交，這樣在提交時更省事。
-
項目實施：項目實施應當做好時間規划，何時做需求分析，何時做架構設計等（可參考下方表格）。有了明確的時間規划，在結對時就有更清晰的目標，對項目進度也有促進作用。
階段 開始時間 結束時間 需求分析 架構設計 具體編碼 代碼復審 代碼測試
CI體驗感想-Z同學
如上圖，我們的結對項目一共進行了92次commit，很難想象倘若缺少CI這樣一個自動化持續集成工具，該如何進行頻繁的迭代式開發測試。
唯一想吐槽Gitlab-CI的是，既然有完善的Terminal界面，如果能開放輸入接口讓用戶能直接在終端進行部分操作，能簡化很多工作。每次修改完腳本后都需要重新提交+漫長的等待時間 屬實有點難熬。
結對編程感想
1 結對的總體感受-Z同學
由於我們二人的選修課時段恰好互補，作息時間也很不吻合(究極夜貓子的我背大鍋)，所以很難做到像書上那樣全過程線下面對面雙人結對編程，因此我們采取的方式是，在每次新任務指導書出來的當天下午/晚上，在新北-1樓面🤺，兩人一起將指導書從頭到尾，逐字逐句翻譯、理解一遍，確保雙方對每個指令/條件理解相同，然后為每個指令編寫一個籠統偽代碼來避免后續由於開發時地理空間位置分開，而導致對指令的理解出現分歧。（盡管這樣的做法在第二次作業中由於細節零碎且需求更改頻繁而慘遭滑鐵盧，但單以第一次體驗為參照，確確實實能顯著提高結對工程后期的開發效率）
結對過程中遇到最大的困難就在第二次任務的后期，具體情況是由於錯誤的預估了各部分任務的復雜程度導致任務量分配較為不均，以及前期沒能完全理解各項指令的要求，本着”走一步是一步“的理論一頓亂燉(無論是單元測試還是代碼實現)，造就了最后兩天瘋狂向各路大佬詢問+看issue+壓線debug的窘態 (祈禱OO老師和助教看不到
結對編程的優缺點第一次博客已經總結了，不再重復。而通過我們兩周的結對體驗，我們最大的體會是：針對線下面基和線上合作兩種工作環境，要分別采取不同的交流方式，以保證合作融洽且高效的進行。即由於在線下大家面對面，交流的機會更多，這時可以暢所欲言，提出自己各方面的針對項目、隊友的意見，這樣二人可以當面協商探討。而線上由於場地因素，許多交流都通過微信聊天框實現，而文字所能傳遞的信息相較面對面口頭會少很多，因此更需要精煉語句，對話時省略掉不需要對方知曉的細節，用"做了什么/哪里存在問題，原因是xxx"的格式精煉概括，將微信中的文本對話當成兩個bot間的問答，能更有利於同伴直接獲取自己的進展，同時啟到記錄的作用（類似commit中的注釋），效果如下圖：
2 緊張刺🤺的互評環節
L To Z
說實話，能熬夜寫代碼到如此之晚（有一次是到了6點嗎，太狠了），你的韌性令我佩服。我在DDL臨近時還沒完全理清指導書的要求時幾乎就要放棄了，但你的堅持也讓我重振勇氣陪你一起熬夜（雖然說到3點就頂不住了）。不過我覺得你在第二階段的時候有很多意見都沒有說，這不僅影響了我們之間的溝通，還把你自己搞得悶悶不樂。既然是結對，就應該深入地交流，不能因為小問題（當然可能並不小）破壞了結對的氛圍。很期待今后仍有合作的機會。
Z To L
仔細一想這並不是我們第一次結對了，上學期證據法學課上也有過合作，總的來講和你組隊體驗都很不錯，大家都對學習和成績有明確的目標，這也保障了我們對結對項目都有着責任心，不會出現兩人都是”等等黨“，都在等對面先急了開始攬活，然后自己能繼續摸魚的詭異情況。
BTW，在結對的過程中我也向你提出了一些意見，希望能對你有所幫助：
- 在針對隊友完成的項目做出評價，或者給出自己見解的時候，不要光說”這個不好/這個不對“，而是要同時給出對修改完善項目具有可行性的見解，至少也要說明不好的原因，例如”我認為這個不好，改成...better/這里有問題，因為...“，具體可參考漢堡點評法中的說服(Persuasion)。因為我們是一個項目團隊，我們最終的目的都是將這個項目做完，做好，大家的目標是一致的。To be honest，在緊張的開發階段，如果隊友的書寫有錯誤/實現的有缺陷，他更希望聽到的是別人對"該如何進行更新/修改"提出建設性的意見，而不是單純的站在高處評價隊友所做的工作的好壞，這樣可能會影響到隊友的開發熱情。
- 在許多時候要更為主動的去給自己安排工作/找事做，而不是等隊友來安排。因為在結對項目中我們是平等的，沒有所謂的leader（可能有會更好？仔細一想這或許就是所謂的領導力，既能自身掌握全局，統籌安排，還能在白臉紅臉間自由切換：同伴失意時加以鼓勵，同伴犯錯時當面指出糾正）。性格偏外向的我在項目初期階段可能會作為溝通的主動方並宏觀上的分配任務，但到了后期事情越來越多越來越雜，我自己處理起來較為費力的時候，我就很難做到在完成自己任務的同時把控好全局的項目進程，這時就需要你自身去篩查我們的項目還差什么，還有什么漏洞，有就主動去填補，而不是細致到發現一個小bug都要來詢問這個bug該由誰來修改，畢竟這是我們的項目，屬於我們需要共同維護的”財產“，因此無論是誰發現了問題都應該是要搶着去完善。
最后，需要向你道歉的是，可能由於我屬於那種半個急性子又愛面子，不太擅長當面向隊友提出意見和要求的人，導致在第二次作業最后的階段，我看到還有很多問題沒解決，線下合作的效率又很低時，還固執的把很多活往自己身上攬。導致自己生了一些悶氣，也間接影響到了你，抱歉，這不是一個理智的隊友應該做的事，我會努力改正，同時期待下一次更加完美的合作 [orz.gif]。
3 使用的工具-Z同學
IDEA、JUNIT、GIT、GITLab-CI、Ubuntu、微信、Genshin Impact (巧合間發現：原來你也玩...)
4 感想&體會&吐槽-Z同學
第一次結對作業的體驗極佳，任務簡單+指導書清晰明了，讓我們很好的踐行了《構建之法》中所說的
結對編程中駕駛員和領航員的角色要經常互換
這不僅避免了長期工作帶來的觀察力判斷力下降，還保證了我們雙方對對方書寫的代碼親密度達到100%，直接免去了后期測試/debug時的代碼閱讀難度。
第二次結對作業，emmm，完全就是另一種情況了。
總的來講，4.5號晚10點DDL結束后，我和我的小伙伴的樣子大概是這樣的：
（內容過於寫實遂打碼）
像經歷了一場曠日持久戰爭一樣，即使勝利了眼神里仍帶着一絲麻木。
可以說助教團隊用千變萬化的指導書着實讓我們體會到了如何應對未來客戶飄忽不定的需求，但YYSY模擬的還是太過於逼真了，許多例如CP指令遇到dst、src的文件類型不同時該如何處理沒有官方明確的說明，盡管到最后發布了如”不會測試該類數據“的issue，但也無法時空回溯，挽回開發階段在這些方面耗費的時間。
盡管進行任務時的體驗確實有億點煎熬，But，Every coin has two sides (非套話.jpg)，整個結對項目結束后，回想起大家為了一個目標一起通宵討論問題+分配任務+捕蟲到4點，還是十分充實且收獲頗多的。
另外，感謝yyh、wcf、lcy同學和zbm、cookie助教的幫助，解答了我在指令上的N多問題。敬禮、禮畢。