提問回顧
在學期伊始，我閱讀鄒欣老師的《建構之法》的時候提出了幾個不太了解的問題，當時寫下的部落格連結如下：【軟體工程】第1次個人作業
當年提出了如下幾個問題：
-
問題1：re-work是否能夠衡量代碼的品質呢？
這個問題我目前認為書中說的不無道理，re-work的多寡确實并不和最終的品質成正比，但re-work還是可以一定程度上反應工程品質的。正如部落格中所認為的，在着手具體編碼實作之前的設計，其目的就是為了減少甚至避免re-work，而如果re-work較多，則說明設計不夠到位，也就說明之前的工程品質出了問題，我仍然堅持認為這個邏輯是沒有錯的。
-
問題2：函數中goto的使用？
其實這個問題提出的原因是，書中說往往會使用goto函數來設定唯一出口，但老師告訴我們不要使用goto語句，或者說設定唯一出口的目的是什麼呢？為了友善測試？還是什麼呢？由于在團隊中沒有擔任開發工作，是以這個問題目前我還沒能得到能夠令人信服的答案。
-
問題3：結對程式設計真的利大于弊？
真的！真的！真的！結對程式設計可能是整個學期最有趣的部分了233333！對于兩個比較熟悉的人而言，結對程式設計當真是快樂源泉，還能促進感情（滑稽.jpg）；哪怕是不太熟悉的人，經過快速地磨合，隻要配合得當真的可以高效持續工作，這種感覺原理就好像是，如果一直勻速長跑，會讓身體的疲勞感很強，但如果引入變速跑，比如快跑800然後慢跑200等等，會在保持心率和消耗能量的情況下大大緩解疲勞感，我猜測可能就是有了變化讓人有了新鮮感。
-
問題4：懂技術的PM是否要參與開發？
我們組的兩個PM雖然稱不上懂技術的PM，但也算是懂得如何程式設計、能夠快速通過學習成為開發的PM。但經過了三個階段的項目推進，我意識到在一個團隊中，每個人都有自己的角色任務要完成，PM就好好做好設計，做好使用者需求分析和項目推廣的工作，按時監督項目推進進度就好，沒有必要參與開發的。
-
問題5：優化該何去何從？
好問題，事實是，在Alpha階段這種緊鑼密鼓的急速開發過程中，根本沒時間想優化的問題，Beta和Gamma階段才能回來想想優化。是以我認為，與其說提前考慮優化的問題，不如先設計好，讓項目有充足的可擴充性，然後給後期的優化留下空間。
在項目的需求/設計/實作/測試/釋出/維護階段都學到了什麼“知識點”？
-
需求階段
需求階段首先我們是将自己代入到使用者的立場上，考慮使用者可能的需求，進而進行設計，但想要更有效地進行需求分析，最好在做好産品的大緻需求分析後，找幾位目标使用者詢問下他們的意見，往往他們會提出我們想不到的關注點。
-
設計階段
設計階段的經驗教訓就是，一定要花足夠多的時間在設計上，在設計的同時，也要充分考慮産品的可擴充性，否則就可能會出現，在後面的疊代過程中想要增加新的功能時，發現無法擴充，隻能重構的情況。
-
實作階段
在實作過程中，前端與後端之間一定要積極交流，PM也要起到協助溝通的作用，出現問題了一定要抓緊解決，否則就可能會出現前端等待後端、後端等待前端，導緻項目進度大大延後的局面出現。
-
測試階段
測試任務要随着開發一起進行，單元測試、回歸測試都是必不可少的，同時，最好能對測試人員的測試品質進行檢查，如我們組在Gamma階段時，開發人員突然發現一個bug，而這個bug本應在Alpha階段就被測試出來的。
-
釋出階段
（釋出階段我實在想不出來什麼知識點了……就按時釋出、做好推廣就好……）
-
維護階段
在項目推進的過程中，團隊要維護好項目文檔，一方面這也反映了項目的品質，另一方面如果以後有别的團隊來接手我們的項目，詳細的文檔也可以幫助别的團隊成員盡快熟悉我們的項目。
軟工的心得體會
在團隊項目的Alpha、Beta和Gamma階段，我擔任團隊中的PM，群組内其他成員共同完成了VisualPytorch從0到1的轉變，很辛苦也很榮幸。軟體工程這門課給了我們每位同學一個機會，一個在學校内可以體驗做一個完整工程的機會，這是不可多得的，也是别的學校可能體驗不到的。在項目開發過程中，團隊成員各司其職，也就可以真正感受到自己的責任是什麼，而不是僅僅停留在理論層面的。然而不得不說，作為一門必修課程軟體工程還是存在它的不足的，如：課上内容對團隊項目的推進缺少必要的引導，總體一學期下來的感覺就是，自己完成了一個大作業，期間要寫各種各樣的部落格來完成作業要求。不過，作為一門剛開設幾年的課程，存在不足是難免的，也祝軟體工程這門課程可以越辦越好。