回首往昔，更進一步

這個作業屬於哪個課程	2021春軟件工程實踐 | W班 (福州大學)
這個作業要求在哪里	軟工實踐課程總結
這個作業的目標	軟工實踐課程總結
其他參考文獻	無

回顧與總結

一、提出疑問的博客

問題在這

二、過去的坑

1. 關於代碼規范的一個疑問

   過去，我對第四章4.2中“斷行與空白的{}行”中提到的標准我表示不贊同，並且認為格式C更優於格式D（C是{不換行，D是{換行）。

   現在，我認為不管是哪種標准，都是可接受的，正如汪老師所說的，重要的是在團隊開發之前確定代碼規范，確保團隊成員代碼風格的統一才是最重要的。團隊每個人寫的代碼如果規范不一，那么整體代碼看上去會變得雜亂無章。

2. “從用戶的角度考慮問題”具體可以有什么角度？

   過去，我對第十二章12.1中“從用戶的角度考慮問題”感到疑惑，並且自己去查找資料。一是從書后內容找到了“盡快提供可感觸的反饋系統狀態”、“用戶有控制權”、“一致性和標准化”這些原則。二是網上找到了幾個考慮角度：控制感、歸屬感、驚喜感、沉浸感。

   現在，我通過需求分析、發布時的自我感受和收集到的數據進行分析，對這個問題有了更深刻的體會。就拿我們團隊的項目舉例，“盡快提供可感觸的反饋系統狀態”，發布信息成功后，需要有個提示信息，提示用戶已經發布成功，否則用戶無法立即得知自己剛剛發布的信息是成功發出去了還是失敗了；”一致性和標准化“，對於同一類事物我們需要統一命名，在首頁的二手、任務、活動，在”我的“和”收藏“處，依然命名為二手、任務、活動，有明確一致的稱呼；”驚喜感“，我們在發布的時候可以自定義標簽，用戶可以根據自己的需求自定義標簽，也可以根據自己的需要搜索、篩選自己想要的物品、任務、活動。

3. 關於書本第十三章“驗收測試”中“可用”→“預覽版”的疑問

   過去我通過查詢資料得出來的結論如下：
   預覽版：尚未穩定的測試版。主要用於軟件未來版本的改善與修正。
   正式版：總結了之前預覽版的BUG並修復完善后的版本。
   通過這個定義，大概可以推出一個流程：經過測試確定“可用”→發布“預覽版”供用戶使用→通過反饋收集測試過程沒有發現的BUG問題→修復收集到的BUG信息→修復完畢后發布更加完善的“正式版”。

   現在，我對這個問題有了更新的看法。正如汪老師在評論所說的，測試版雖然近似正式版，但畢竟還有差別，其中缺少了用戶實際使用場景的測試（通常說的β測試）只有經過這個階段的測試，產品才能過渡到正式版。在編碼階段，雖然已經產生了可用版本，即測試版本，但是因為還沒有用戶真正在使用，沒有實際場景的測試（雖然也有10+個人使用），我們的小程序也只是處於一個測試版。而在發布階段，我們先把測試版本發布，有了用戶實際使用場景，並通過用戶使用后給予我們的反饋，我們對存在的問題或需要改進的地方進行了修改，最終才實現了“測試版”到“正式版”的蛻變。

4. 書中對於“要成為領域的專家，才能夠創新”的反駁，我有其他的看法

   過去我和書中觀點一樣，也不贊同這句話，但我還有其他的看法，創新與是不是領域的專家並沒有必然聯系。你不是該領域的專家，就能更容易在該領域創新，這句話也顯然是錯誤的。透過現象看本質，你會發現，創新成功的人，最重要的一點是打破了思維定勢，只是對該領域了解越深的人，就越容易陷入思維定勢罷了，因為你對這個領域太過於了解。所以這個迷思的本質我認為應該是：誰能打破思維定勢，誰才有可能能夠創新。
   現在，我對這個問題看法有了一個新的角度。我認為要創新，打破思維定勢是必要的，而打破他的方式，可以是學習其他領域的知識，嘗試用其他領域的思維方式去創新。之所以我會這么想，是因為一開始我是學習后端的，但是因為團隊的需要加上自己也想學一下前端，所以項目開始后，我開始學習前端知識。通過前端的學習和實踐，從側面更了解了后端應該、可以做哪些事情，也學會了從前端的角度去思考后端，而不局限於后端。

5. 作為團隊的一個普通成員，要如何順利的完成階段的過渡？

   過去我的總結是：
   萌芽階段：盡快適應新的團隊環境，嘗試去了解其他成員，並弄清自己的定位，積極配合領導開始最初的工作。
   磨合階段：如果自身屬於技術能力較強的人員，可以適當發揮自己的技術領導能力；注意與隊友共事、交流的方式是否存在不妥；不要懼怕團隊合作，加強自己的自信心和熱情；碰到確實無法解決的困難，敢於尋求幫助。
   規范階段：團隊的規矩已經定下，盡量不要試圖打破規矩；時刻牢記團隊的目標和決心；承認成員之間的差異性，並且要學習尊重成員。
   創造階段：（這個不清楚）

   現在，在親身實踐過后，我對原本的總結沒有異議，但是有新的補充：

   萌芽階段：如果領導確實有安排的不合理的地方，可以提出適當建議。
   磨合階段：如果團隊的交流存在障礙或者阻力，要盡可能解決，否則會影響到整個項目的進展，對項目有疑惑也可以提出建議。
   規范階段：每個成員需要把項目當做是自己的東西，而不是別人的東西。

三、做中學

1. 需求

   需求分析，在這個階段就要密切關注用戶的需求與動向。要首先站在用戶的角度去做分析，用戶需要什么，用戶缺什么，用戶想要看到什么。在這個階段就要收集用戶的建議，做調查，針對用戶的反饋與建議，調整我們最初的需求，我們的軟件是做給用戶的，不是我們自己的，所以用戶的需求、建議才是重中之重。問卷是個很不錯的收集途徑，而數據是最有力的話語。

2. 設計

   我第一個體會就是，我們之前學習的課程，例如UML、設計模式、數據庫，這些課程的知識，是切實有用而且是必要的，在設計這個階段就體現出來了，以前課程上更多的是學習理論知識，而設計這個階段，就是把之前在這些課程中學習到的知識，轉換成實際操作。類圖設計、數據庫設計、接口設計，種種都需要專業知識的輔佐才能夠進行下去。在類圖設計的環節中，類圖要畫的盡可能詳細一下，而且要多次復審，是否有不合理之處，還可以思考能否用上什么設計模式來輔佐設計。在數據庫設計環節，可以參照前面設計的類圖進行，同時，在數據庫設計過程中，遇到不合理之處，也可以反過來修改類圖。在做大項目的時候，要充分考慮數據庫多對多關系的處理，可以適當建立一些關聯表來聯系不同表。

3. 實現

   實現階段，前端我們做了小程序端和web端，小程序端是重頭戲。我覺得這個階段我最大的收獲還是學會了小程序開發跟前后端交互，小程序開發算是新學到的一項技能，而前后端交互應該算是學會了一種方法，因為前后端交互不管是小程序端還是web端等等都是必要的，通過請求后端接口獲取json數據，並且使用數據進行渲染。

4. 測試

   測試階段，正好這學期學習了軟件質量測試這門課，把這門課學到的黑盒測試、白盒測試以及系統測試學以致用，第一次用專業的測試方法去測試項目。也學會了小程序的真機調試，用它特有的調試方法，配合學到的測試方法進行測試。

5. 發布

   發布階段，真的是吃了很大的教訓，因為α階段有嘗試發布過一次線上版，所以覺得沒有太大的問題。后面β階段要發布的時候，卻被審核告知內容涉及信息發布，不能申請個人小程序，給我們的發布造成了極大的麻煩。第一次做小程序，精力大部分花在了設計、編碼、測試上，對發布的准備沒有做足，以后做其他項目的時候，也要吸取教訓，發布也是提前做足准備才可以，去了解發布需要什么，准備好發布的條件。

四、心得體會

1. 個人項目

   • 養成好的代碼習慣十分重要。這個時候才有的代碼規范的概念，在編碼的過程下意識地遵守自己定下來的代碼規范。
   • 性能問題很重要，代碼優化不好的話，面對數據量爆炸的時候，程序可用性就會下降很多。
   • 測試很重要，編寫單元測試很重要，錯誤要早發現早解決，到后期才發現問題的話，就要付出數倍、甚至數十倍的代價去解決。還應該注重測試方法的使用，白盒測試、黑盒測試、集成測試等的方法都要學以致用。
   • 要善用GIT版本控制工具，對代碼的維護、協同開發有很大的幫助。
   • 平時做其他事情也可以借用PSP表格的思想，對自己要做的事情做預期的規划，可以提高效率，在事后也更容易發現自己的問題。

2. 結對編程

   • 討論很重要，因為不是一個人在做，在開工前就要討論好一些重要的問題，規划好整個項目，不能走一步算一步，這樣的話效率太低，小項目還好，項目一大馬上玩完。同時，可以集中兩個人的看法，求大同存小異。
   • 遇到問題可以上網查找資料，還可以找隊友商量解決方案，1+1＞2，兩個人來解決一個問題，效率要高得多。
   • 分工要做好，誰做什么，要提前安排好，工作才可以有序進行。
   • 學會看官方文檔是非常重要的學習方式。第一次開始系統的學習前端，開始通過看官方文檔慢慢學習，收獲頗豐，更重要的是掌握了一種學習方法。
   • 每天的目標也很重要，給每天設定一個目標，有條不紊的進行，才不會到最后才匆匆忙忙完成。

3. 團隊項目

   • 編碼前的開會十分重要，在開會的時候要盡可能把可能存在爭議的問題、需要統一規范的問題給解決了，把分工做細（適當），確保每個人都有明確的目標去做。
   • 成員之間的合作很重要，這點在交互的時候尤為突出，交互的時候可能涉及多個人的代碼，要解決交互中出現的問題，成員之間需要密切交流並且耐心地面對可能出現的問題，我很慶幸我們團隊內部氛圍很不錯，大家都合作的很愉快，也都很有耐心。
   • 很多感想體會已經在團隊博客寫了，這邊就不再復制粘貼，最后，很感謝能成為“那你能幫幫我嗎”團隊中的一員。（我怎么說了那么多很重要）

個人技術總結

小程序端實現分頁

概述：當小程序端需要請求的數據特別多，但是不要求一次性顯示出來的時候，可以使用分頁，在需要的時候再請求下一頁內容。