| 這個作業屬於哪個課程 | 2021春軟件工程實踐 -W班 (福州大學) |
|---|---|
| 這個作業要求在哪里 | 軟件工程實踐總結&個人技術博客 |
| 這個作業的目標 | 課程回顧、個人技術總結、技術分享 |
| 其他參考文獻 | 《構建之法》 |
課程回顧與總結
回顧問題
回顧自己列出的5到10個問題：嘗試解答、繼續分析、提出新問題
問題博客鏈接
- 問題1
在進行一個較大的項目時，我們經常會進行合作完成，這樣的話就會加快項目的進程，但是此時成員之間交流想法分配任務以及每個人完成任務后在整個項目的整合中會有很多問題，我們如何解決這些問題呢？
嘗試解答：就說說這次的軟工實踐項目，這個項目算是一個較大的項目，至少對於我來說是，然后我們團隊在開發過程合作的可以說是相當順利，各個階段的任務完成的很不錯。這都離不開團隊中每個人的努力。現在來說說我們團隊間如何交流想法分配任務以及最后的項目整合。首先應該是解決前后端分配問題，組長先請大家發表自己的觀點，一輪下來后端人數明顯居多，這個時候為了不影響進度就要有人做出犧牲，沒記錯的話組長由后端改到了前端；其次是任務分配，我們小組采用的是自取方式加組長分配，這樣子每個人可以選擇自己比較感興趣的部分，如果重疊的話再進行協商，如果沒人領取的話組長在進行分配。能力較強的可以負責較難的部分；能力較弱的可以負責難度適中的部分。都是在學習的過程中，能力較弱的也是可以選擇難的部分，不懂的虛心請教並不丟臉。（大家都很積極，我記得alpha沖刺后面我還去要了些任務做，差點給隊友都做完了）；最后就是項目整合，我們小組解決的方式是集中開發，這樣子能夠較好的對接，負責某一后端接口的與負責前端對應部分的成員對接，如果出現雙方都解決不了的問題時還可以求助其他成員來更快的解決問題。
渠道：軟工實踐經歷
繼續分析與新問題：上面所述的解決方法只是我們小組在軟工實踐中采取的，那如果是公司內團隊，也可以采用上面的方法解決問題嗎？對於不同公司不同制度而言，結論應該是不同的吧。
- 問題2
在軟件開發之前如何去了解它是否符合大眾生活需要？
嘗試解答：一個好的軟件，很大程度上取決於對要解決的問題的認識，以及如何准確的表達用戶的需求，需求分析就是要解決這個問題。訪談、情景分析，編制系統規格說明文檔，創建原型等，是獲取真實需求了解軟件是否符合大眾生活需要的有效方法。
渠道：軟工實踐經歷
新問題：除了上述說的方法，我們還有其他方式去了解軟件是否符合大眾生活需要呢？
- 問題3
用戶體驗與產品質量為什么會沖突？一個好的軟件是應該追求好的用戶體驗，還是應該所追求好的產品質量，或者是折中？
引用老師的評論：有些bug很少的高質量產品，用戶體驗卻很差。
嘗試解答：我記得老師評論過后我還是不能理解，我依舊認為：高質量的產品無疑具有較高的性能和很少的bug，而bug的多少可以直接衡量一個軟件的用戶滿意度，所以高質量產品應該是對用戶體驗的一個提升，因此用戶體驗與產品質量應該不會沖突。經歷了軟工實踐，我意識到自己的觀點是錯的，就比如一個沒有bug的產品但是用戶玩不明白和一個可能存在潛在bug的產品但是更多的考慮的用戶體驗，后者肯定是相對“好”的產品，我們設計產品的源於需求，需求來自用戶，用戶玩不明白，難道設計后是給開發者用的嗎，雖然可能可以做相應的用戶引導，但是如果產品的初衷就是為了方便，那就不太好說了。對於現階段我的理解是一個好的軟件既要追求用戶體驗，也要追求產品質量。低用戶體驗，再好的產品質量也無濟於事；低產品質量會降低用戶體驗。
渠道：軟工實踐經歷
- 問題4
應該根據什么來選擇在哪方面追求“專和精”？
引用構建之法：沒有人能在學校里掌握所有“將來會用得到的知識"才離開學校.隨后馬上把技術運用在實踐中。工程師應該在實際工作中不斷學習和不斷成長，根據自己的情況選擇在哪個方面追求“專和精".在哪幾個方面達到"知道就好”的水平”。
嘗試解答：是否可以說我們應該在那些常用知識技能結合自己的能力去做到專和精，要學會運用知識的思想，而不是單單某個具體的主流技術，因為主流可能隨時代變化，但真正的原理、思想還是類似的，要學會舉一反三才是真正的學明白了。
渠道：軟工實踐經歷
- 問題5
團隊中角色與職責有必要自然轉化嗎？
引用老師的評論：這里所說的角色、職責能夠自然轉換並不是指要求成員能夠勝任任何一種技術，這不現實。更多值得是在團隊中擔任什么角色應承擔相應的職責。
嘗試解答：我認為團隊中角色與職責有必要自然轉化，就好像這次軟工實踐，原先后端選手居多，組長最后由后換前，在前端位置承擔自己相應的責任，這就是角色與職責的自然轉化，這可以說時很有必要，有利於保持進度的一致，不會因為哪一端進度慢，最后出現聯調來不及的情況（一個例子就是，github實訓時有一個組后端人員就兩個好像，最后接口對不上）。
渠道：軟工實踐經歷
新問題：如果這種轉化確實發生，但是轉過去的人對那部分知識一點都不熟悉，對於原來那一部分卻了如指掌，那這個轉化后的效率真的會比原來的高嘛？
做中學
5個階段中，每個階段收獲最大的知識或能力是什么？
-
需求
需求分析我參與的並不是很多，但是也學會了站在用戶的角度思考問題，換位思考，切身想像用戶在使用產品時會希望產品怎樣有效的幫助到用戶。而不是開發者本身想要什么。以及考慮需求可行性，比如以開發者目前的能力能否很好的實現需求。好在我們處於學習階段，開發的周期對於我們是充足的，我們可以嘗試着學習未知領域的知識。 -
設計
這一塊我主要負責的是數據庫設計方面，然后在后面開發過程有遇到因為數據庫設計缺陷而導致實現部分功能較困難或者說實現起來不是那么通俗易懂，沒有必要那么麻煩，導致反過頭來修改數據庫表結構的情況出現。所以我意識到了這個部分的重要性。同時要注意接口文檔同步更改並且及時通知隊內所有人（我們組來說相對好點，某同學所在小組修改了接口文檔內容沒有通知之前實現的人，導致這個人最后做了無用功，使我印象十分深刻！），隊內及時的溝通很有必要。 -
實現
這是我第一次較為正式的和團隊完成一個完整的項目，實現過程我學會了獨立思考，以及通過各種途徑尋找好的解決方案，然后可能是負責的部分相對簡單，所以有時候閑下來我會去看看隊友寫的代碼，學習了SpringBoot文件上傳以及Sa-token、Spring Security等知識，讀別人代碼其實也是一種學習的途徑，走別人的路少踩點坑。同時學會使用阿里巴巴插件規范代碼。 -
測試
鍛煉了SpringBootTest單元測試的使用，應用了軟件質量與測試課程里的部分知識，收獲了黑盒測試以及使用JProfiler進行性能測試的能力。其實這幾個階段，隊內及時交流都是很有必要的。在接口文檔上，不但要明確各個接口的各個參數、返回值以及接口本身的意義，然后任意一方修改接口時，要及時的交流，否則后果可能會多做無用功。 -
發布
微信小程序發布最好提前ddl幾天，然后發布后也要進行相關測試，有bug及時修復。
經歷的理解與心得
結合自己在個人項目/結對編程/團隊項目的經歷，談談自己的理解或心得
個人項目
- 通過這次個人項目初步學習單元測試，之前的測試方法都是直接運行程序，十分不便，但是使用單元測試，可以更加方便地對特定代碼進行測試（這個程序比較小，當時還沒有意識到測試要與開發同步進行）；還學會了使用JProfiler進行性能分析。
- 復習了git和GitHub的使用，較為正式的使用了git工具進行項目管理，再一次感受到了用git工具管理代碼的優越性。
- 使用PSP表格進行預估，事后可以更容易發現自己的問題所在。
- 最大的感想就是作業要早點做，不要拖到ddl，意外隨時可能發生，早點做既能夠降低風險，又能夠讓老師助教提前點評，發現不足的地方可以及時改進。
結對編程
- 結對作業一（原型設計）：相較於個人作業確實是花費了更多的時間，但換來的是較於個人實現來說整體效率以及質量上的提升，畢竟是1+1>2，一個人不容易發現的問題也許會被另一個人發現，一個人解決不了的問題也許另一個人剛好知道問題所在。這次原型設計是和老同學進行的，過程的分歧比較少，但是實際工作中可能會遇到和陌生的人進行設計，理解方面雙方偶爾意見是會有出入，這是需要我們花時間去討論來產生一個合理的中間方案。
- 結對作業二（網站實現）：這個作業里可以說是完整的學習了Spring MVC的開發流程，從入門到最后較好的運用。但是過程可以說是慘不忍睹，在實現完之后有些配置我依舊是不太明白，配置這些東西我記得把我搞得半死，但是后面JavaEE這門課我較為系統的學習了，現在回過頭來想想也就是那么回事，所以理解原理是很重要的，一頭霧水的學真的很累。遇到困難多百度，再無法解決求助別人，自己死磕效率真心不高。
團隊項目
- 第一次正式以一個后端成員參與一個完整項目，是一個很不錯的體驗，也是將自學的SpringBoot知識運用的一個經歷。
- 合理的分工安排以及時間規划，效率自然就上去了。
- 隊內有效的溝通合作很重要，一個Team就要有Team的樣子，不能說從頭到尾自己做自己的，最后整合的時候問題百出。
- 代碼規范要提前規定好，可以看起來比較舒服，也可以方便隊友、老師、助教或者其他人閱讀。
- 測試要與開發同步進行，否則可能聯調會出現問題，會增加不必要的時間成本。
- 心得就是很幸運很開心能夠遇到我的隊友們，和優秀的人在一起就確實是會進步，學到了很多東西。
個人技術總結
博客地址
概述
一個功能強大且高度可定制的身份驗證和訪問控制框架