| 項目 | 内容 |
|---|---|
| 這個作業屬于哪個課程 | 2021春季軟體工程（羅傑 任健） |
| 這個作業的要求在哪裡 | 提問回顧與個人總結 |
| 我在這個課程的目标是 | 鍛煉軟體開發能力，學習團隊協作方法 |
| 這個作業在哪個具體方面幫助我實作目标 | 對軟工課程做一個總結回顧 |
| 以前提問的部落格 | 建構之美——個人閱讀作業2 |
一、提問回顧
問題1
教材2.1.2中寫到單元測試必須由最熟悉代碼的人（程式的作者）來寫。代碼的作者最了解代碼的目的、特點和實作的局限性。是以，寫單元測試沒有比作者更适合的人選了。作者提出單元測試必須由代碼作者來編寫，因為代碼的作者是最了解代碼的人。但人的思維都是有局限性的，如果代碼的作者真能思考到代碼的方方面面，那就不會有那麼多bug了，而且很多bug也正是由于代碼作者寫代碼時候的思維局限性所導緻的。
是以筆者認為單元測試可以由代碼作者來參與編寫，因為代碼作者确實更了解代碼，知道怎樣更快的寫好單元測試。但與此同時，也應該有非代碼作者的參與，非代碼作者往往能提供不一樣的思路，有角度不同的了解，更容易想到代碼作者的思維盲區，這樣寫出來的單元測試才能更加全面。
經過這學期軟工課程的學習，對于單元測試也有了更深入的了解。當然，單元測試由代碼作者與代碼作者之外的人共同參與效果會更好，但在團隊項目的實踐中，發現其實并沒有那麼多時間，那麼多人手來做測試。這種情況下顯然是由代碼的作者來寫單元測試更為合适，在時間并不充裕的情況下，相對于其他人而言，作者能更快地寫出覆寫更全面的單元測試，這也是一種對資源的最大化利用。
問題2
教材3.1中寫到對于這些任務，一個成熟的軟體工程師應該能夠降低任務傳遞時間的标準方差。如果你能長時間穩定而按時地傳遞工作的結果，内部和外部的顧客就會對你的工作有信心，更喜歡與你合作。作者認為一個任務傳遞時間穩定的軟體工程師，大家會對他更有信心，更喜歡跟他合作。如果所有人都這麼認為，會不會是以導緻很多軟體工程師可以更短時間内完成任務卻特意花更長時間呢？因為他們不能保證每次都可以在短時間内完成，另外畢竟市場和公司都喜歡任務傳遞時間穩定的軟體工程師，這樣拉長時間還更加輕松，何樂而不為。
當然從整個行業生态來看，在這種傳遞時間穩定更好的标準下，偶有這種能力資源的“浪費”也是可以接受的。但是否有更好的衡量标準可以避免這種“浪費”呢？
通過團隊項目的實踐，發現誠如助教所言，在團隊合格的管理制度下，以及配合燃盡圖、代碼送出、issue等方式，可以大緻看出任務的完成度，PM也可以很好的規劃團隊每個成員的任務，很大程度上可以防止“摸魚”現象的存在。在軟體開發過程中，也發現了任務穩定按時傳遞的重要性。在每次配置設定的任務量差不多的情況下，如果團隊中一個成員有時傳遞一個任務隻需要一天，而有時卻需要好幾天，這會打亂團隊的整體任務規劃，會導緻一些需要疊代的任務難以進行。
問題3
教材4.3.2中寫到函數最好有單一的出口，為了達到這一目的，可以使用goto。隻要有助于程式邏輯的清晰展現，什麼方法都可以使用，包括goto。作者認為隻要有助于邏輯清晰表達，使可以使用goto的。猶記得大一時接觸c語言時，老師特地說過不要使用goto，goto雖然好用，但會使程式結構混亂。
于是抱着疑惑查閱了相關資料，發現主要有兩種觀點。一種就是不提倡使用goto，因為容易把邏輯弄亂且難以了解；另一種提倡使用goto，因為在跳出多層循環和異常處理時比較友善且效率高，很多大型項目、開源項目，包括linux都會巨量的出現goto來處理錯誤。是以比較好的标準就是在錯誤處理的時候使用goto，其他地方都禁止使用goto嗎？
在本學期的軟工課程中并沒有使用到goto，不過經過團隊項目的實踐，還是很認同助教的觀點“在團隊項目中盡量限制”。對于大佬而言，goto可以簡化邏輯，但在團隊合作中，如果需要閱讀含有goto的代碼，那會變得非常頭痛。
問題4
教材8.5中寫到殺手功能（Core）/外圍功能（Context）
除此之外，我們的競争對手和使用者已經決定了一些此類産品必須要滿足的需求，不能滿足這些需求，産品就入不了使用者和評論員的法眼，當然，還有許多功能是輔助性的。這樣，我們又得到另一種劃分：
必要需求（MissionCritical）/輔助需求（Enabling）
這四種劃分結合起來，就得到了功能分析的四個象限。我們以一個英漢詞典軟體為例子來說明。
在教材後面也提到了，比較核心的功能要盡量做的好，達到行業最佳，而那些輔助性的、外圍一點的功能則可以以最低代價來維持，甚至不做。
但現實中很多情況下這樣做不太合理，很多軟體的核心功能由于行業技術水準的限制，做的再好也就那樣，使用者甚至感覺不出來有什麼差别。但那些外圍、輔助性的功能反而是使用者最能感受到差别的，比如界面操作的舒适度，比如有多種皮膚，使用者可以自由定制。很多原版的軟體和遊戲不火，反而那些抄襲的軟體或遊戲被更多人歡迎，這些抄襲軟體甚至再在核心功能上對比原版軟體還略有不如。但就是因為它能提供舒适的操作界面，個性化的定制，容易上手等非核心特性，反而與其他軟體拉開了差距，取得了勝利。
經過團隊項目的實踐，對這個問題的思考有了一些變化，核心功能是開發者眼中最重要的，但在使用者眼中，使用舒适度才是最直覺的。但還有一個問題，核心功能是核心競争力，如果核心競争力沒有勝過其他軟體，那麼已經使用習慣了其他軟體的使用者不會因為界面更加好看等原因來使用你的軟體。是以最好還是能做到核心功能與外圍功能兼顧，既要做到有核心競争力，也要有讓使用者使用體驗更好的細節。當然，如果實在是資源不足，那還是要優先完成核心功能。畢竟使用體驗再好，核心功能不行，這軟體也是沒人會用的。
問題5
教材16.1.5中提到統計資料表明，70%的創新者說，他們最成功的創新，是在他們的拿手領域之外發現的。第一眼看到這個70%，就覺得難以相信。但經過仔細思考，覺得可能是一種統計偏差。當叫你去思考拿手領域外的創新時，你可能随便就能說出很多，但因為并不了解哪些是可實作的，哪些是有實際意義的，是以可能你說的99%的創新都是無意義的。而如果讓你去思考領域内的創新，你可能思考半天也說不來，原因之一是長期處于這個領域，思維會被束縛，另一個原因則是你相比于外行人，更清晰地知道哪種創新是真正可行的且有價值的，是以在思考中就把很多想法給斃了。
是以在拿手領域外創新其實并不比領域内容易，隻是思考方式可能與那個領域的工作者不同，加上“不知者無畏”，可以提出很多有意義或無意義的想法。此外，創新者就算在拿手領域外有了一個好的創新想法，最終還是需要那個領域内的工作者來将這個想法改進、細化，使這個想法真正有實作的可能并具有實際的價值，其實這個過程也算是一種“創新”。可以說是創新者提供了一個思考方向，領域内的工作者依着這個思考方向進行創新。
對于這個問題的思考大抵還是與以前相同，或許會有少數人在拿手領域外進行了創新，但他們隻是提供了一個思考方向，而領域内的工作者則依着這個思考方向進行創新。
二、在實踐中學習
需求
在需求分析階段不能自己主觀認為有某些需求，而需要采用發問卷等方法調研是否真的存在某些需求。在定需求時要多與潛在使用者溝通，積極征求建議。NABCD分析是一種很有效的方法，可以更明确的确定軟體需要的功能。
設計
設計階段需要充分調研某些技術，避免技術風險。在團隊協作設計中，還需要使用原型設計，UML圖，ER圖等來進行交流。設計階段還需要考慮充分，設計完善，避免在開發過程中發現需要增加新功能等情況，打亂開發計劃。
實作
在團隊合作中，例會非常重要。既能有效推進項目開發，也能防止某些成員“摸魚”。PM通過例會也可以更好地把控團隊開發進度，以及每個成員的開發情況。發現有些成員任務量過大時可以動态進行調整。實作過程中文檔也很重要，如代碼設計文檔，接口文檔等，一有改變都需要實時更新并通知團隊所有人。
測試
測試應該最開始就有一個測試計劃，單元測試還需要在開發階段随着代碼的編寫同步進行。如果全部代碼都等到最後階段進行集中測試，那修bug可能修到讓人絕望。在開發階段結束後要進行的測試應該是壓力測試，性能測試等。
釋出
釋出階段需要團隊積極宣傳，宣傳也是一門技術，是以最好還是有專門的宣傳團隊。但在本學期的軟工項目中，還是要發動團隊中每個人都為宣傳貢獻一份力量，如制作海報，寫宣傳語，制作宣傳視訊等。
維護
維護階段需要積極收集回報并進行更新，對軟體進行日常維護等。對于使用者回報中bug相關的問題需要及時修複，對于一些功能的改進建議等需要收集整合，在下一階段的疊代開發中可以參考。
三、個人總結
本學期的軟工課程終于落下帷幕，從個人部落格作業到結對程式設計，再到團隊項目，花費了大量時間投入到了這門課程中，也從中收獲了大量知識與經驗。
個人部落格作業幫助我對軟體工程有了一些理論上的認知與思考，但僅僅隻有理論沒有實踐，是以還存在着很多疑惑，之後的結對程式設計和團隊項目則是真正的實踐，許多疑惑在實踐中一一印證，得到了解答。結對程式設計通過與夥伴進行合作程式設計，認識到了代碼規範的重要性以及設計的重要性。在團隊項目的例會中學習到了溝通交流的重要性，團隊中各成員分工合作，完成各自的任務，最終做出一個團隊項目，這個中體驗還是比較有趣的。從這門課程中學會了很多，交流、合作、規範、設計......，學到了很多技術、能力，更大的收獲是寶貴的經驗。
經過這學期的軟工課程，對于軟體工程中的各種方法有了更深入的了解，也收獲了寶貴的實踐經驗，相信在之後的項目開發中，這些寶貴的經驗都會派上用場的。