| 專案 | 內容 |
|---|---|
| 這個作業屬於哪個課程 | 2021春季計算機學院軟體工程(羅傑 任健) |
| 這個作業的要求在哪裡 | 提問回顧與個人總結 |
| 與本作業對應的部落格 | 《構建之法》& CI/CD調研 |
| 我在這個課程的目標是 | 提升軟體開發能力與團隊意識 |
| 這個作業在哪個具體方面幫助我實現目標 | 總結本學期軟體工程心得體會 |
1. 問題回顧
- 學期初的提問連結：《構建之法》& CI/CD調研
1.1 敏捷軟工過去的團隊專案後來怎樣了？
學期初提出這個問題，是因為這門課的助教很多都是去年敏捷軟工的參與者，我想也許可以在評論區得到回覆（雖然並沒有）。而在一學期的課程接近結束的當下，這個問題本身已經變得不再重要，更重要的問題在於——謎語人隊的團隊專案將會怎樣？我們對“觀隅”的未來抱著怎樣的期許？在《構建之法》的尾聲，幽默的語調正道出殘酷的現實：
維護階段：課程結束了，同學們對自己的產品沒有任何維護，放假了！
最後，大部分同學都說這門課特別沒用，自己根本沒學到什麼東西，老師特別爛。然後下個學期，新的一批學生會重複這一過程……
僅就專案的可維護性而言，我對於觀隅還是抱有自信的：無論是前端的元件化設計與嚴格的Typescript約束與Husky自動檢查、抑或是後端完備的單元測試與說明文件，還有我們“不需要之一，絕對是最棒”的CI/CD流程（wpbyyds），我想如果有新成員並且對React或者Django有一定了解的話，是可以快速融入到開發工作中的；不過關於觀隅本身需求的目標合理性與目標完成度，Beta階段評審的結果顯然更有說服力，我想這裡就不必鞭屍了orz。
這幾天Beta評審時被羅傑老師指出的本地化做的不夠好的Bug已經修復，其他評審表中談到的佈局問題和配色問題由於本身的技術難度與審美難度，感覺確實沒有維護的動力。觀隅的故事在我們的手中已經告一段落，也許在開源到csdn或codechina之後，又會有新的續集呢？
1.2 單元測試由最熟悉程式碼的人來寫是否足夠呢？
學期初我的想法是：單元測試同時應該由模組的設計者進行，因為他們對於整體功能有清晰的把握，能克服個人理解程式碼的侷限性。而在本學期結隊專案與團隊專案的實踐中，我對於單元測試的作用又有了新的理解：
- 結隊專案階段：這是本學期敏捷軟工比較艱難的時期，由於需求說明書的複雜性，在做單元測試時僅靠個人的力量是很難覆蓋所有情況的，因此通過Issue區的線上討論與組內的線下討論，不斷豐富測試用例與覆蓋率，才能通過強測。
- 團隊專案階段：後端的情況我並沒有深入瞭解，但應該是達到了課程組的要求；而前端部分雖然有諸如Mocha、Jest這樣的測試框架（我們使用的React預設整合了Jest），但不同小組都心照不宣地沒有做前端的單元測試。
為此，也許可以從敏捷開發的工作流程中做一些“辯護”：後端理想的開發流程是TDD(Test-Driven Development)的，因此通常要求達到90%以上的單元測試覆蓋率，從而保證每一次迭代都處於預料之中；而前端則更接近於BDD(Behavior-Driven Development)，注重對行為以及某個具體需求進行測試，前端的單元測試也是近幾年伴隨著Web應用複雜度的提高而興起的。
在我們實際的開發中，一方面我們開發的Web應用是單頁面應用，整體並不複雜，RD的每一次瀏覽都是在驗證前端行為與程式碼的正確性；另一方面，觀隅前端開發的掣肘在於React陡峭的學習曲線以及由此帶來的一系列人力緊缺問題，很多時候由於中英文資料較少，框架本身迭代快，往往需要花費比預期更多的時間，在一次次的失敗中摸索出某個具體問題的最佳實踐。因此最後前端的測試做得並不好。
說到這裡看上去有些跑題，但其實答案早已明確：如果條件允許，單元測試當然是越多越好，除了程式碼的編寫者進行測試，也由模組的設計者等進行測試。而伴隨著前端業務邏輯複雜度的提升，為了防止程式碼自身的劣化與成為重構的絆腳石，單元測試也是必須的。
1.3 2021年，“全棧工程師”們都去哪裡了？
在第一次作業閱讀提供的往屆優秀部落格中，我看到很多學長的職業規劃都是成為一名全棧工程師，然而這個詞語如今似乎早已不再流行，提供的崗位也比職責更加明確的前端、後端少了不少。在網上搜尋相關的問題，大部分回答都在勸退：一方面更加明確的分工是大勢所趨，企業所需要的是可替換的人才；另一方面過多的領域也讓全棧工程師難以深入鑽研某一個方向。
在我們的團隊裡就有一位“全棧工程師”。他既是組長，也負責資料集解析，後來還負責後端使用者介面實現，再後來還到前端調CSS和寫資料視覺化，最後的答辯也是由他進行的。而在公司之中，伴隨著RD對業務的熟悉與自身能力的精進，往往也會不再侷限於單純的需求開發，而開始同時承擔PM（自己提出新的技術需求）、DA（進行資料分析）的工作（參考物件：我的Mentor）。
“當我們談論‘全棧工程師’的時候，我們說的究竟是‘交響樂作曲家寫各個樂器的樂譜’，還是‘演奏家滿場奔走，操作各種樂器’呢？”，我想“全棧工程師”這一職位的消失反而是好事，因為這一名詞所試圖描述的也許就是不僅有紮實的技術功底，還能對整體工作帶來促進作用的人才。而經過本學期軟工的抗壓能力、產品需求分析能力、市場推廣能力以及程式設計能力訓練之後，在座的各位都有著成為一名優秀的全棧工程師的潛力吧。
1.4 結對程式設計在雙方差距較大時的意義是什麼？
結對程式設計的一個重要作用就是由老手帶領新手迅速熟悉開發環境，新手可以得到及時反饋，從而快速融入到新環境中。
在團隊專案階段，我們組內在衝刺階段和Debug階段時用到了結對程式設計的方法。Debug時，每個人都會基於自己的理解提出可能的解決方案，類似於進行頭腦風暴，對於最後解決問題也是有啟發意義的。
雖然大多數時候是幾個小時過去了，結對成員依然在不斷嘗試……
1.5 如何避免A/B Test提升執行成本？
觀隅並沒有進行A/B測試，一方面我們的使用者體量小，另一方面目前實現的功能比較簡單，沒有太多對比優化空間。
良好的程式碼規範以及基礎設施是能降低A/B測試成本的，比如建立面向PM和RD的A/B測試申請平臺，完善審批流程，在程式碼中定義清晰的A/B測試規範，都能減少A/B測試帶來的開銷。
2. 新的問題
2.1 引入新技術需要考慮哪些問題？
坦言之，使用React+Typescript這一我們並不熟悉的前端技術棧，是觀隅開發遇到的最大的阻力。這是我在Alpha階段負責決定前端技術棧時犯下的最大的錯誤，也對前端團隊帶來了負面影響。如今回想還是在於對於團隊所不熟悉的技術缺乏長時間的調研與可行性評審，最後增大了開發難度。
雖然初衷是美好的：Typescript能對型別起良好的約束作用，避免JS本身動態性引起的問題；React Hooks能讓開發者聚焦於動作結果，減少了心智負擔；Material UI 符合谷歌設計規範，貼近人工智慧所承載的科技感。但實際開發時出現的種種Bug和資料不足的問題卻造成了很大的困擾，很多時候為了使用一些其他框架又不得不跳過ts的檢查……最後看來並沒有達到預期。
第一次，有了喜歡的UI庫，還得到了ES新特性的加持，還有與Vue對應的另一大框架，三份喜悅相互重疊，這三重的喜悅又帶來了更多更多的喜悅，本應已經得到了夢幻一般的幸福時光，然而，為什麼，會變成這樣……（白學家落淚）
2.2 如何讓測試用在刀刃上？
在Beta階段展示時，我向題士組進行了提問：他們的各類單元測試、壓力測試都做得很好，但在UE/UX方面，卻因為按鍵熱區太小，使用者往往需要多次點選才能命中按鈕，在一定程度上影響了使用體驗。這確實是難以被量化，卻又與使用者體驗最緊密相關。是否能讓測試更加聚焦於關鍵問題，能否從測試標準上解決這一問題呢？
3. 實踐中學到的知識點
3.1 需求
我們所選擇的是課程組提供的選題，團隊中大部分成員其實並沒有系統地學習過深度學習相關知識，因此NABCD分析對於這一階段來說是必不可少的。通過流程化分析可以讓我們從使用者角度考慮問題，儘快從適應階段過渡到正軌中。
3.2 設計
設計階段需要明確產品提供的功能，在開發過程中可能需要結合實際情況砍掉一些優先順序不那麼高的功能。此外設計也可以理解為整體使用者互動的設計，在這次團隊專案中我負責了最開始的Mockup原型設計與最後的觀隅整體風格統一，在這個過程中我也在不斷吸收借鑑其他產品的使用者介面。
雖然這與CS專業本身所學的知識似乎並不佔邊，但好的介面無疑能讓自己的產品在多個同型別產品中脫穎而出，模仿是設計階段的最佳實踐。
3.3 實現
比起錦上添花，更重要的是先有個MVP（最小可用實現）。前端相比後端，任務量其實是難以界定的：給文字框套個矩形，可以說是完成了某個頁面；但你新增適當的陰影間距增加轉場動畫後，這個頁面可能依然沒有完成……
當然，產生這一結果最主要的原因就是缺少專職的UI給出統一的設計，但對於軟工小組來說基本是不可能的，所以就需要面臨不同人寫出的元件大不相同的問題。在這種情況下最重要的還是確保基本功能，會視覺化資料集的觀隅就是好魚。
3.4 測試
覆蓋率等只是測試的最低要求，壓力測試、互動測試等同樣重要。測試的根本是為了改善產品體驗而服務的：為了能夠快速開發出新版本、保證功能正確性、使用者在高峰時期依然能順利訪問、使用者能順利互動等。
3.5 釋出
宣傳對於釋出階段來說是非常重要的，要選擇目標人群進行精準推廣。
3.6 維護
提供直觀的反饋入口，儲存引發問題的日誌，並及時回應使用者的反饋。
4. 個人總結
4.1 個人部落格
在個人專案階段寫了三篇部落格，目前來看讀後感與調研、案例分析都對最後的團隊專案有了不小的啟發：
- 《構建之法》把軟體工程中的概念細化拆解，讀起來生動並不枯燥，讓我對軟體工程中的工作流程與人員分工都有了初步瞭解。也正因如此在團隊專案階段，我們格外注重CI/CD的使用。
- 案例分析作業我選擇的是CSDN、牛客、知乎App的對比賽道。在後來設計觀隅的原型時，我也在從當時的分析汲取靈感。
4.2 結對程式設計
結對程式設計階段和駕駛員T佬度過了一段愉悅的摸魚時光……T佬是我們小隊的掌舵者：當我們初次討論需求與實現時，他提出先寫介面文件的標準化流程；當我在第二次結對部落格中輸出情緒時，他能從理性的角度向課程組提出自己的建議；當我們的結對時間由於種種原因難以對齊時，他能給出行之有效的處理方案……再次感謝T同學。而從結對本身來說，我第一次體驗了Pair Programming，這是從個人到團隊的過渡。
4.3 團隊專案
人是複雜的生物，如何處理好不同人的訴求，讓每個人的力量都能作用在最後的目標上，是協作的一大難點。而統一的程式碼風格、標準化的文件、嚴格的准入檢查……現代軟工正是通過一系列標準化的流程，最大限度掃清協作的阻礙。因為實習每週有一半時間在打工，在團隊專案中我的投入並未達到預期，觀隅的主要可用頁面都是dsy在寫，非常感謝隊友的包容。
5. 個人感悟
寫這篇文章時是我實習的Last Day，回想起過去的幾個月就如同夢一般。也曾滿懷期待，也曾失態，也曾沉浸在釋出的喜悅，但如今心中反而只剩下平靜。
我想這門課對我的影響是很大的，讓我讀到了一本很好的書，對於軟體開發的工作流程有了實際體驗，因為感覺自己能力不夠而從選擇就業到選擇繼續卷讀研。而建議部分，能否在初期就通過計劃書等方式鼓勵學生自主選題，如把選題加入到個人作業中？
希望敏捷軟工越來越好。