| 項目 | 内容 |
|---|---|
| 課程 | 2020春季計算機學院軟體工程(羅傑 任建) |
| 作業要求 | 提問回顧與個人總結作業要求 |
| 個人部落格作業連接配接 | 個人部落格作業 |
| 我的課程目标 | 掌握軟體開發的方法論和諸多技術，與同學合作開發出好的軟體。 |
| 本次作業的作用 | 回顧以往提出的問題，總結學期收獲。 |
一、對學期初問題的解答
· 問題：單元測試的編寫者
當時提出這個問題是覺得由于編碼者自身思維不周全而導緻的bug不容易被本人發現。然而，在實際的軟體開發過程中大部分時候不會涉及過于複雜的算法。實作一個典型的軟體功能（如對元素的增删改查）所涉及到的算法難度并不大，但是卻橫跨了前後端，在“橫向”上比較廣。而在快節奏的開發中，其他組員往往不能對某項功能的代碼了解得十分細緻，是以由作者對自己編寫的代碼進行測試是最合适且高效的。當然，如果某項核心業務的确設計到複雜算法，那麼還是值得為它專門投入更多人力去測試。
· 問題：goto&異常處理
在軟體開發中，關鍵是要保持各部分代碼的可讀性和代碼習慣的一緻性。在實際開發中，我們會編寫文檔對代碼加以規範。goto的自由的确可能導緻代碼變得不好了解，但是在大多數簡單邏輯下并不會造成太大影響，有時反而能使邏輯更清晰。異常處理也是一樣，關鍵在于以統一的方式進行處理。
· 問題：why agile？Sprint過程中需求的變化
經過一個學期的體會，靈活開發的方式的确是十分高效的。即便是對程式設計語言尚不熟悉的情況下，每天的SCRUM Meeting上也可以專門抽時間請教經驗豐富的同學，或者形成臨時的二人結對小組，通過觀看的方式快速入門。上手開發後，如果在某個技術問題上遇到很大的困難，也可以及時調整政策選擇其他路徑。
縱觀現在的應用軟體市場，幾乎所有APP都在以幾天或一周為周期高速疊代，随時解決着新問題與新需求。這也是因為如上提到的，當軟體已經大體成型時，解決一個已發現的問題，或是面臨一個新需求時，所要做出的改動或增量開發并不會太多。當然，有時也确實會遇到任務量很重的情況，比如一個遊戲公司發現他們現有的引擎已經無法滿足玩家對畫質的需求，決定更換引擎。而一次Sprint的時長也是根據預估的任務量而定，核心便在于以最快的時間完成新功能。
· 問題：創新的迷思
現在回看書中的觀點，感到非常認同。首先，作為軟工新人，最應該關注技術上是否熟練，能否快速寫出“足夠好”的代碼。那些最終實作了創新的高手，大多都是從小就熟練掌握了技術。其次，創新并不僅僅局限于技術，當今很多非常成功的軟體在一開始并沒有基于太深奧的技術，而是能敏銳地發掘的人們的需求，并在背後實作了商業模式的創新。創新本身并非目的，關鍵還是在于解決實際問題。
二、軟工知識點總結
- 需求分析階段
- NABCD需求分析架構。
- 在分析過程中形成UML圖作為需求分析階段的最終輸出。
- 設計
- FDD功能驅動的設計。
- 由于我們組是在以往代碼的基礎上進行增量開發，更加适合這種設計模式。基于需求建構出新功能，并分派至各個成員，是我們小組的典型工作方式。
- 實作
- 源代碼管理平台GitHub的使用。
- 在開發過程中挖掘了GitHub如Issue管理、Commit與Issue之間的關聯等功能。
- 測試
- 驗收測試。
- 在基本完成兩個階段的開發後，交由測試同學進行一次完整的測試并針對問題建立新Issue。驗收測試中往往能發現一些各子產品之間關聯性的問題。
- 釋出
- 從使用者的角度審視。
- 在Alpha階段釋出前的展示中，羅老師提出讓我們從使用者的角度審視平台，這給我們帶來很大的啟發，發現了很多跳轉不夠合理以及功能設計不夠人性化的問題。在Beta階段解決了大部分問題。
- 維護
- 收集使用者回報。
- 釋出之後積極關注使用者回報，除了能快速解決一些暫時的問題（如伺服器問題），也是提煉下一階段開發任務的機會。
三、心得體會
軟工課程的每一個階段都帶給我非常深刻的感觸和收獲。
個人項目時我經曆了一次比較大的算法改動。由于美賽占據了很多時間，以及對C++尚不熟練，臨近最後發現掃描線算法難以完成，而當時又沒有形成一個可用版本，是以十分焦急，連夜換回了最基礎的算法。這次經曆給了我很好的教訓，當對基本内容尚不熟悉時，不應想着一次實作較難的算法，而是應先着重于整體架構的設計與實作，并快速完成一個可用版本。然後再對其分析、優化。這樣在節奏上更加穩定。
在結對項目中我主要負責後端新功能的實作以及優化。在這個過程中，我充分關注了C++不同資料結構背後的實作方法。第一次在實踐中體會到算法與資料結構之間密不可分的聯系。的确，競速的要求會在一定程度上給人壓力，然而伴随着時間精力的投入，一定能有所收獲。畢竟使你的程式更快是實實在在的知識。在我最終向隊友傳遞成果的時候，他指出我應該打開VSCode自帶的編譯優化選項，這一下子又使程式的執行快了一大截。一方面，共享知識使我收獲了一個實用技巧。另外從技術的角度講，優化的确應該考慮整個過程中的每一個環節（核心是性能瓶頸的分析）。
而團隊項目是我第一次與一個集體協作開發。每天繁多的學習、開發任務的确讓我感到許多壓力。然而在隊友的耐心指導下，這種壓力便完全轉化成動力。在團隊開發過程中組員在技術上互相幫助，之間的友誼也更進一步。我們小組在合作模式上經曆了多次轉變，從最開始适合入門的小組結伴模式，到每人都能獨立完成新功能的開發。良好的合作模式使得每位同學的優點被最大化為團隊所用，每位成員都做出了不可替代的貢獻。
本學期的軟工課使我感到非常充實。