提問回顧與個人總結

提問回顧與個人總結

項目	内容
這個作業屬于哪個課程	2021春季計算機學院軟體工程(羅傑 任健)
這個作業的要求在哪裡
我在這個課程的目标是	在結對項目和多人團隊項目中，更加系統地學習軟體開發，培養工程化的思維
這個作業在哪個具體方面幫助我實作目标	回顧本學期課程經曆以及自己對課程的感悟
個人部落格	提問部落格連結

一、問題解答與分析

單元測試應該産生可重複、一緻的結果......單元測試的運作/通過/失敗不依賴于别的測試,可以人為構造資料，以保持單元測試的獨立性。

Q1：書中的說法是否過于絕對？當針對多線程尤其是死鎖等偶發性的問題進行測試時如何保證單元測試可重複性？另外，進行壓力測試時，單元測試的運作會依賴别的測試，顯然不滿足書中所說條件，那我們難道就不測了嗎？

我認為，單元測試主要是對代碼邏輯進行的測試，并不能代替壓力測試、黑盒測試等其他測試方式，是以也不必檢測應當由其他測試方式檢測出來的可能的問題。換句話說，多線程、死鎖等問題的測試應當出現在壓力測試或者是公測階段，而不是由單元測試來解決，單元測試隻應當針對某一段邏輯複雜的代碼，并且單元測試的結果應當是可重複的，這樣能夠驗證代碼邏輯的正确性。

在單元測試通過以後，應當繼續進行壓力測試。在壓力測試遇到問題時，測試人員應當及時調取相關的日志檔案并儲存下現場（例如記錄發生死鎖的線程編号或者引起系統崩潰時的資源占用率），并且撰寫出bug文檔傳回給開發人員進行修改，這樣能夠最大限度地彌補單元測試無法針對這類不可複現問題的缺陷，進而提升測試的效果。二者應當相輔相成，互為補充。

這個問題的答案是我們小組進行測試時我思考得到的，一開始我總是試圖用單元測試來代替其他各種各樣的測試方式，後來發現單元測試并不能覆寫所有可能的異常情況，因而重新将單元測試的重心放在代碼的邏輯上。

項目/任務有多大？說到項目的大小，一般用代碼行數來表示......也可以用小時、天、月、年來表示......也可以用re-work（返工）的次數來表示

Q2:項目/任務的大小應當由什麼名額來決定？我認為書中的答案隻在特定前提下才能夠很好的衡量工作量。

我認為，書上給出的用代碼行數來衡量的方法是不準确的。以上學期的編譯課設為例，有的同學編譯器代碼隻有3000+行，而有的同學代碼量則達到了7000+行，能說後者的工作量是前者的兩倍嗎？顯然不行。由于每個人采用的算法不同、架構不同，會導緻代碼行數有所差異，用代碼量衡量會有失偏頗。我認為，應當用代碼行數的數量級衡量項目的大小。我們的大作業代碼行數的量級是千，一般的iphone應用代碼函數的量級是萬，鴻蒙作業系統、谷歌浏覽器代碼行數的量級是百萬，通過這些資料能夠大緻比較項目的大小，對于量級相同的工程我們可以認為其大小大緻相當（除非使用的語言有較大的差異，例如一個項目使用底層彙編語言，另一個項目使用python等較為進階的語言）。

在小組合作的過程中，我發現在大家都對unity 3D不太了解的情況下，因為組内的各個成員能力水準相差不大，可以使用投入時間來衡量任務的大小。有時候，為了調用合适的接口函數，可能需要閱讀各種各樣的接口說明書，了解清楚了以後才能進行調用，這樣看起來代碼不長，但是背後所花費的時間是巨大的，是以此時使用代碼量來衡量工作量就有失偏頗，而使用花費的時間來衡量就更能反映任務的實際難度。

在企業裡，要衡量一個任務的大小，可以用普通員工完成該任務上花費的時間來确定。何為普通員工？在這裡，我說的普通員工并不是某一個具體的人，而是一名能夠代表社會平均勞動生産率的員工，即業界平均水準的程式員完成該任務所需要花費的時間。

軟體團隊和客戶代表要在需求階段把這些問題（指對産品功能性的需求、對産品開發過程的需求、非功能性的需求、綜合需求）給搞清楚。

Q3:能在需求階段就把這些問題都搞清楚當然最好，但是實際情況往往是使用者并不了解自己的需求，或者軟體團隊無法準确擷取使用者在表述中隐含的需求，此時應當怎麼辦？

首先，在任務開始前應當盡可能詳細地調查使用者的需求。經驗表明，使用者的對于産品的最基礎需求往往是能夠通過調查得到的，這些需求大多是功能性需求，然後根據使用者的需求開發出滿足使用者最基礎要求的最小化版本。其次，對于使用者的興奮需求，我們認為是可以被誘導出來的。換句話說，應當通過團隊的自主設計來引導使用者的需求（例如，在網站上制作出一些精美的動畫，讓使用者使用時感到驚歎不已；或者是我們在開發遊戲的過程中盡可能的壓縮遊戲的大小，為使用者節約流量等等）。這些功能我們設計出來了以後，即使使用者在使用之前沒有設想到會有這些需求，在使用過程中也會因為提升了體驗感而起到加分的作用。通過團隊合作開發項目的過程，我明白了自行設計并進行優化的重要性，優化過的産品往往能夠滿足使用者隐含的需求。

我平時接觸的同學都說計算機專業的，我平時上的網站都geek味或者hacker味十足......原來我并不了解海量中國使用者，原來真實的使用者并不是我想象的那樣。我不了解為什麼360的裝機量那麼大，但實際上有海量的使用者不懂得如何管理電腦軟體；我不了解為什麼hao123能有那麼大影響，但實際上有海量的使用者并不會直接輸入常用網站的網址；我不了解為什麼那麼多人願意在QQ上為虛拟形象付費，但實際上有許多年輕女孩願意花錢來為自己在社交平台上的形象打扮。

Q4：這個人不了解大多數使用者的需求是因為他本人是計算機專業的，他周圍接觸的人大多都是計算機領域的，是以他認為的使用者和實際情況相去甚遠。而企業做調研報告的時候，回收的樣本往往也會由于回收樣本的群體不同而使得結果産生偏差。怎樣盡量減少偏差？

在團隊項目的過程中，我們在開發之前先通過調研等方式得到了典型使用者，我們的産品是針對典型使用者開發的。是以，我們的調查結果隻要針對這一類典型使用者群體的準确的，就能夠讓我們開發出來的軟體有較高的使用者滿意度。換句話說，隻要回收樣本的群體是我們遊戲的主要閱聽人，那麼收到的結果就是可信的。

PM(Program Manager)和大家平等工作，推動團隊完成軟體的功能......一個團隊可以有很多PM......PM管事不管人。

Q5:PM沒有上司權，會不會導緻團隊裡的開發者偷懶？PM的工作配置設定很難做到平均，由于不存在上司關系，是以難以有效管理？創新不僅需要個人魄力，還需要有權力才能推動？

通過這次團隊合作的經曆，我們的PM李辰洋完美地用行動回答了以上問題。在一開始，我們就制定了獎勵措施和懲罰措施，對于拖ddl、耽誤小組進度的同學會有嚴厲的懲罰；同時，由于我們有着嚴格的出口條件和驗收标準，使得組内的開發者難以渾水摸魚，這樣就杜絕了偷懶的現象。關于配置設定工作的問題，PM會私下調查同學們掌握的技術棧并在每項工作配置設定之前統計意向，優先給各個同學配置設定自己擅長、感興趣的工作，這樣能夠有效調動成員積極性；如果實在需要有人委屈、犧牲去做一些沒人願意做的工作，在事後PM會征得大家的同意後給予一些補償（例如配置設定更多的貢獻分等等），盡可能地平衡大家的付出與收益，進而有效地完成配置設定任務和管理的工作。每一次在遊戲内的創新都是PM上司大家做調研、開組會探讨得到的，在組會上我們會積極探究一個方案的可行性以及技術難點，在取得大家的認可了以後才會進行，是以對于我們而言創新是一個組的事情而非PM一個人的事，不需要PM去強迫大家來做，也不需要PM通過權力去push大家。這種自發性讓我們在提出新的idea後能夠更好地落實和實施。

二、學到的"知識點"

需求

需求分析階段最重要的知識點是NABCD，即需求、做法、好處、競争、推廣五個方面進行分析。

對于使用者的需求，我們小組采用的方法是面向典型群體進行調查和采訪。我們通過微信問卷、朋友圈提問等方式收集了不同年齡段使用者對于輕量級手遊的需求，掌握了使用者的整體需求量。此後，我們針對部分典型使用者（例如高中生、在校大學生）進行了一對一的采訪，傾聽使用者真實的聲音。應該說，需求分析對于我們的産品定位具有重要意義，也對我們日後的開發産生了指導意義。通過調查需求量的大小，我們得以選擇合适的伺服器；調查使用者的使用習慣我們實作和優化了許多遊戲内部的細節。從使用者中來，到使用者中去一直是我們開發産品的初衷，通過需求分析，我們明确了許多在開發階段應當注意的事項。在具體做法上，我們盡可能發揮了組内成員的優勢，讓善于寫前端的同學去完成UI部分，讓有豐富遊戲經驗同學去開發遊戲邏輯部分，這樣他們能夠在開發之前有較為長遠的規劃，對于項目周期的估計更加準确，遇到問題時更好地拿出解決方案。好處是産品主打的優勢，是項目能夠讓使用者産生良好印象的關鍵。我們團隊通過自主設計一些能提升使用者滿意度、滿足使用者興奮需求的細節來提升産品的競争力。在同類遊戲産品中，我們的遊戲占用記憶體小，遊戲大小較小，運作流暢，能夠在低級别的作業系統上相容。而這些優勢，也提升了我們的競争力。在推廣上，我們也深深明白推廣一款新遊戲的不易，但我們還是盡可能地在更多途徑進行宣傳，例如制作網頁、在朋友圈轉發、制作推送等等。同時，我們還注意到，由于在周末使用者的需求量會有所提升，是以推廣的時機也應當盡量選擇在周末，這樣使用者更有可能有時間去嘗試。

總體而言，在項目中我更加生動地感受到了NABCD的全過程，對于具體的實作細節有了進一步的體驗。

設計

設計主要用到了技術規格說明書和功能規格說明書。我們在說明書中大量使用了表達控制流(Flow Chart)來進行設計，這種圖利用類似狀态轉移的方式幫助我們理清複雜的邏輯，非常直覺易懂。同時，我們的功能規格說明書将驗收标準也包含進去了，這對于後面的測試和交叉互測非常有幫助。有了驗收标準和指定負責人，實作了責任關系的明确化，一旦出了Bug能夠很好的溯源和追責，也展現了設計階段對于項目全過程的統領作用。

實作

本人在團隊項目參與了遊戲界面的部署以及網絡部分的同步，學到的知識點是避免重複造輪子，以及如何選擇合适的輪子。

在部署許多子產品群組件的時候，應當最大限度的利用官方已經提供的接口，Unity3D是一個強大的元件，有許多的内置功能，而有時我因為懶得去翻閱官方的文檔而走了很多的彎路，許多元件的配置都從頭開始一點點用代碼實作，而實際上這些配置隻需要通過圖形化界面下一鍵點選即可完成綁定。同時，官方提供了非常強大和全面的接口，在閱讀完傳入參數和後置條件以後即可使用，而不是自己嘗試用原始的方法來完成任務。同時，選擇合适的輪子非常重要。在部署伺服器時，有三四個開源的接口可以選擇，如果沒有慎重選擇的話，可能會因為伺服器的限制（例如最大支援的連接配接數量的限制或者是不支援全雙工通信等問題）而遇到麻煩，如果在項目的後期才遇到這種難以避免的問題可能會導緻進退兩難的情形。是以，在前期調研技術棧時應當盡可能詳細，要對接下來的工作有了大緻印象以後再選擇合适的輪子，確定能夠實作基本要求以後再選擇合适的輪子。

測試

在團隊項目中，因為前端單元測試難度較大，是以沒有進行規範的單元測試。我們采用的是人工測試，讓多個使用者去體驗産品，我們意識到有時人工測試是必不可少的，因為機器測試對于出來明顯的卡頓和延遲，而人工測試能夠及時發現前端方面的此類問題，我明白了不能過度依賴機器測試，畢竟我們的産品是面向使用者的。

同時，我還明白了交叉互換、由他人進行測試的重要性。在結對程式設計階段，由于我對于指導書産生了誤解，按照自己錯誤了解書寫了代碼，并且自己根據錯誤的了解書寫了測試程式，是以并沒有能檢測出Bug。而交叉檢查能夠很好地避免這個問題。我學習到了在可能的前提下應當盡量由另一個人來進行單元測試。

釋出

釋出主要學到的知識點就是：學會合适的時機、合适的平台進行推廣。

我們發現，在周末進行推廣的效果明顯優于在周中進行推廣的結果，說明使用者在周末會更加有時間浏覽并下載下傳遊戲，選擇好了時機就能夠事倍功半。同時，我們發現在QQ群推廣的效果明顯不如微信群，猜想這可能和使用者的使用群體和使用量有關，QQ的使用量較少或者QQ的使用群體不如微信的使用群體對遊戲熱衷，是以在後期我們主要通過微信推廣。我學習到了合适的推廣管道能夠提升推廣的效率。

維護

維護階段主要學會的是把握好版本更新的時機。

如果版本更新過于頻繁，可能會使使用者不厭其煩，同時也會消耗使用者過多的流量，對于沒有wifi的使用者不友好；版本更新太慢，則一些bug不能及時得到修複，一些嚴重的Bug可能會嚴重影響使用者體驗。

三、了解和心得

個人項目

本學期的個人項目，主要就是閱讀給定材料和部落格的撰寫。

通過個人閱讀作業#1,我嘗試着整理和思考了自己已經走過的路，對于未來的職業有了初步的規劃，明确了自己的軟體工程這門課中應當學習到什麼、應當有什麼樣的收獲。

通過個人閱讀作業#2，我閱讀了《建構之法》，對于軟體工程這門課的整體架構有了了解，還學習到了提問的藝術。另外，我還學習到了一整套關于軟體工程的體系，了解了如何完成工程化、高品質的軟體工程。同時，對于CI/CD工具的調研讓我掌握了使用該工具進行自動化測試的基本流程，為團隊合作項目中自動化測試提供了幫助。

而後的案例分析作業中,通過對市面上已有軟體的使用和BUG親自嘗試，讓我大緻了解了目前已經走向市場、開始盈利的項目所應當具有的水準，也讓我明白如何系統性的分析和對比市場上不同軟體，了解軟體評測基本方法。

結對程式設計

結對程式設計其實某種意義上是一次兩個人共同完成的OO作業。相比于以往的OO作業，結對程式設計的好處在于有小夥伴來互幫互助，可以幫助自己了解還可以幫助自己測試，最大的難點在于如何做到1+1>2。我認為，要想做到1+1>2，首先要有良好的工程規範，變量的命名應當盡可能的通俗易懂，但凡有使用小技巧的地方一定要加注釋，能夠進行代碼複用的部分盡量進行代碼複用。如果能夠做到以上幾點，在隊友進行代碼複審時，就能夠讓對方快速讀懂自己的代碼，免去雙方因為誤會而耽誤時間，起到高效溝通的作用，同時也為後續的疊代開發打下良好的基礎。然後，雙方共同寫代碼的過程中應當盡可能地做到高效溝通，盡量在一開始就把可能的問題給闡述清楚，避免越說越糊塗。此外，把控好自己的情緒非常重要，我的隊友陳偉明在遇到困難時及時安慰我，調節雙方的情緒，還非常體貼地在我筋疲力盡時送上小零食小甜品，讓整個團隊的氛圍更好，讓我們結對程式設計的效果更佳。在結對程式設計的過程中，我看到了陳偉明身上的種種閃光點以及他的人格魅力，我們收獲的友誼無疑是結對程式設計給予我的重要經曆。

團隊項目

首先，很高效自己能夠和一群優秀的隊友共同開發出弈魂遊戲。在軟體工程課程之前，我也曾參加過包括馮如杯、實驗室在内的項目開發，但是軟工的項目是周期最長、過程最完整的項目。本項目設有alpha和beta兩個階段，每個階段都有需求，設計，實作，測試，釋出和維護的完整流程，而之前的項目往往都集中在開發階段，不需要進行需求分析，也幾乎不需要長期維護，偶爾需要自己設計一些細節，但是整體的架構都已經有成熟的架構了。通過這一次完整的項目經曆，我明白了需求、設計對于後期開發工作的指導作用，也深刻認識到了詳細的功能規格說明書、技術規格說明書對于日後的開發有多麼重要。同時，在合作交流中，我明白了如何與他人協商，如何在組内協調好與組員之間的關系，達到平衡和協調，讓每個人都能在自己擅長的領域發揮出最大的價值。最後，我們共同完成的一個功能完備、界面美觀的遊戲，我的内心有巨大的成就感，這也是團隊項目帶給我的最大收獲。

最後，感謝發際線和我作隊全體成員的辛苦付出!