| 問題 | 内容 |
|---|---|
| 這個作業屬于哪個課程 | 2021春季計算機學院軟體工程(羅傑 任健) |
| 這個作業的要求在哪裡 | 提問回顧與個人總結 |
| 我在這個課程的目标是 | 系統了解并參與軟體開發過程，提升自身工程能力 |
| 這個作業在哪個具體方面幫助我實作目标 | 回顧學期初提出的問題，總結課程收獲 |
閱讀提問
問題一：熟悉解決低層次問題與提高技能
正确地調用方法是一個低層次問題，但當方法各異、重載衆多時，耗費時間和腦力來熟悉解決此問題，對提高技能有幫助嗎？
關于這個問題，我的看法與先前一緻——幫助甚微。不過，這有個前提，供調用的各個重載方法的底層性能是基本一緻的。編輯器的代碼提示雖然會提示方法的名稱、參數、傳回值等，但是不會提示方法的性能。開發人員需要了解各個方法的性能，以便對具體的編碼進行優化。
問題二：注釋
在實際開發中，當程式實作邏輯無法通過程式本身展現時，如果不在注釋中描述程式的部分實作邏輯，遇到不同的開發人員進行項目對接，如何保證對接的順利或重構的高效呢？
寫注釋不僅有利于項目對接順利，也有利于項目日常維護，但如果對任何方法都寫注釋，則隻會白白增加開發工作量。在我的開發過程中，我隻對那些實作邏輯較為複雜，同時被其他方法普遍調用的方法編寫注釋。
在第一階段的開發過程中，由于初學前端架構，我将頁面不恰當地劃分成了多個元件，使得元件互動十分混亂，導緻後續在此頁面上開發的隊友需要仔細梳理代碼結構（我相信這是十分痛苦的）。于是，在第二階段，我将這個頁面進行了重構，将若幹不必要劃分的元件檔案統一到一個檔案，并做好相關結構注釋，極大提升了代碼結構的易讀性（個人認為）。
問題三：goto
在實際開發中，允許使用 goto 嗎？
現在看來，這個問題并沒有什麼實際意義。項目開發過程中，團隊一般會制定一套編碼規範，如果規範不允許使用，那就不使用；如果規範允許使用，那就根據個人編碼習慣選擇是否使用。
問題四：結對程式設計
在實際開發中，結對程式設計通常以什麼樣的形式開展？結對的兩個人在技術棧、性格等方面有什麼要求？
真正體驗過結對程式設計後，我對這個問題已經有了答案。在結對程式設計過程中，我和隊友一人分析需求，一人具體編碼，偶爾交換工作角色，使得每一個需求、每一行代碼都被兩個大腦了解、檢驗了一遍。
但我又産生了新的疑問：結對程式設計的價值展現在哪裡？
在課程中後期的團隊開發過程中，我們團隊的開發任務按照子產品進行配置設定，各子產品之間互相獨立，負責某個子產品的人員具有最大的自由度設計和實作該子產品。整個開發過程，結對程式設計從未得到應用，如果應用，開發自由度勢必得到制約。
結對程式設計強調代碼時刻處于複審過程，強調及時發現并解決問題。但實際上，我們團隊有專門負責測試的人員，大批量資料砸下去，如果有鍋，複現流程一回報，執行邏輯一檢查，鍋很快就修好了，效率非常高。
問題五：項目經理
項目經理是否應該熟悉基本的開發流程和相關技術？
我很幸運，我所在團隊的項目經理都有着豐富的技術掌握，這樣的體驗是極佳的。當項目經理熟悉一定的技術細節時，開發人員與之交流起來會很順暢。一個懂技術的項目經理，可以和開發人員一同讨論任務實作流程，正确估量任務難度和預期完成時間，保證整個開發過程的有序進行。
做中學
需求
- NABCD是非常有效的需求分析方法。
設計
-
遵循設計的一些方法論。
很遺憾，到第二階段，我才讀到一些有關互動設計政策的書籍，并頗受啟發。
實作
- 當實作細節越來越繁瑣，同時心态越來越煩躁時，大膽重構。
-
接口文檔應安排一定時間來細細商定。
在第一階段的接口文檔中，我将“檔案夾”用category指代，将“名稱”用title指代，于是一個“檔案夾名”變量會命名為categoryTitle，恰好後端還沒糾正我。現在想想，folder和name不香嗎，少打多少個字母啊！
測試
- 密切關注測試人員的回報結果，保持詳細的溝通。
- 準備好及時修鍋，尤其是嚴重影響使用者體驗的鍋。
釋出
-
不能輕視宣傳，應當仔細商定宣傳内容。
在第二階段中，我們的重點宣傳手段是向哔哩哔哩投稿宣傳視訊。但恰逢競品橫空出世，他們收獲了近三十萬播放量，我們僅收獲了幾千播放量。分析原因如下：
- 宣傳時間較晚。
-
宣傳内容值得進一步商榷。
我們的宣傳視訊從介紹傳統背單詞的弊端開始，逐漸引出我們的項目，但背景資料顯示，絕大多數使用者隻觀看了視訊的前幾十秒，壓根沒耐心看後面的項目展示；而競品的宣傳視訊一開始就是項目展示。
從結果上看，我們忽視了短視訊火爆的社會現狀。我們的宣傳視訊，如果用于答辯展示，效果會較好，因為觀者沒有主動放棄觀看的選擇，且看到視訊後半部分的項目展示可能會産生試用興趣；但用于推廣，想要讓别人主動從頭看到尾，顯然是不太現實的。
- 固有問題，隻支援電腦或平闆使用。
維護
-
及時收錄回報，及時修鍋。
目前的視訊播放量還在緩慢增長，也偶爾有使用者申請進入内測群。我們軟體的鍋确實較少，小的鍋很快就能修好，大的鍋主要是部分裝置的适配問題和未來可能的推薦使用模式等，非一時能修的。
個人心得總結——I just code.
我是一個異常難産的人，極度不擅長寫文字，這從幾次部落格作業的低分中也可以看出來。一學期走下來，我唯一的感慨就是幸運。結對程式設計階段，雖然我和隊友共同承擔編碼任務，但主要的總結部落格都是隊友撰寫的。團隊開發階段，我更是沒有負責一篇團隊部落格的撰寫任務。雖然但是，軟工課程帶給我的感受還是異常深刻的，尤其是遇到了這麼多優秀的夥伴。
結對程式設計階段，我和隊友一同看指導書，畫架構圖，分析實作邏輯、算法性能，借鑒彼此優秀的編碼習慣，收獲頗豐。
團隊開發階段，我則充分發揮了團隊賦予我的開發自由度，與大家共同協作完成了一款完備的網頁軟體。在項目臨近結束同時考試密布的時候，我對原來的工作區頁面設計不滿意（按鈕過多、檔案夾欄可展示檔案夾個數過少、檔案夾欄占螢幕面積過大導緻詞圖預覽在平闆等裝置上過小、分頁導緻檢索功能出現問題、未設定緩存導緻頁面跳轉後再次進入時加載時間過長等），希望進行重構。雖然重構意味着不确定性，但我有這樣的自由度選擇重構，最終也沒有辜負團隊的期望。
于我而言，在軟工課上，我不僅收獲了前端開發的技術，為未來的工作積累了寶貴的開發經驗，更收獲到了珍貴的友誼，了解到了各個隊友的優秀。這真的是無價之寶。