| 這個作業屬於哪個課程 | 2021春軟件工程實踐|W班(福州大學) |
|---|---|
| 這個作業要求在哪里 | 作業要求 |
| 這個作業的目標 | 回顧與總結實踐歷程 |
| 其他參考文獻 | 《構建之法》 |
課程回顧與總結
回顧問題
回顧自己列出的5到10個問題：嘗試解答、繼續分析、提出新問題
以前提問題的博客鏈接
- 問題1
在軟工實踐課程中，我們究竟會以怎樣的程度讓之前、或是下學期所學的知識得到應用？
在軟工實踐的過程中，我理解到：應用所學的知識與否完全取決於自己。與軟件工程實踐相關的先修或者本學期同步修習的課程包括：面向對象分析與設計、軟件設計模式與體系結構、Web程序設計、軟件質量與測試、軟件項目管理、人機交互以及基礎編程語言課等等。印象比較深的比如：在系統設計階段應該主動去思考能否應用適合且有效的設計模式；軟件質量與測試課學到的（或本就會的）測試手段與度量標准等在個人、團隊作業的測試階段也得到了應用；個人作業對編程基礎的小鍛煉，結對作業2與團隊項目開發也讓我回顧了Web程序設計的技術；還有軟件項目管理這一過去不常接觸到的領域，在項目管理課程中我選用了本次軟工實踐的項目作為答辯題材，理論知識得以應用到了團隊沖刺的管理過程。這些都讓我學到了不少東西。
很多東西不是依賴於課程要求你去做，而是要主動思考能否應用得上，並且軟件設計本來就要求以上的所有這些東西（還不止）。
- 問題2
《構建之法》第五章開始提到團隊合作的重要性，但每個人的開發能力高低各異，因此在以往的實踐課中團隊工作分配常常是一個頭疼的問題，試問作為尚未就業的軟件工程學生，該如何更好地鍛煉團隊分工協作能力？
實踐過程中我們團隊的溝通是比較良好的，也確實是一個“個人的開發能力高低各異”的小組，分工協作方法簡單來說就是一開始每個人提出自己能做到的，主動認領分解后的子項任務。能力較強的同學可以負責較難的技術攻關，多做一點；能力較弱的同學可以負責其他難度適中的部分，查缺補漏。最后每個人的工作量多少也很公正的反映到了績效評分上。而開發過程中要為人坦承，及時溝通，有不會的大可虛心求教。
通過這些，我覺得我的團隊分工協作能力確實得到了鍛煉，這大部分也歸功於組長和隊員們人都很好。具體的在本篇博客的團隊項目的經歷心得中還會提到。
- 問題3
關於PSP表格的疑問
對於在本次作業中第一次接觸到的PSP表格，它有何意義？
引用老師的評論：之所以第一次作業就引入PSP，並在每次作業中要求PSP表格，就是讓同學們在一次次作業中學會任務分解、事前對子任務預估時間、子任務安排、事后回顧總結，這樣的工作習慣。
談到工作效率與時間管理，這涉及到在書中學到的一個“二八法則”，其中時間維度的解讀是：“花20%的時間會產生成果的80%。”，這就告訴我們把有限的時間，拿來處理最為重要的事情，不要浪費時間的重要性。而PSP表格便是進行這一步的一種工具，在實踐中呈現為我們記錄每次的工作環節，預期計划與實際耗時，從而度量我們的學習、工作效率，總結出現的問題（效率低下的環節），吸取有效的經驗（做得較好的部分）。
這與其實早在中學時代就出現的，我們統計做考卷各類題目的用時，考察自己哪個模塊薄弱，不斷改進以求更優異成績的環節是一致的，只是現在應用到了更實踐性的事物里了。
- 問題4
TDD通過明確的流程，任務分解、列Example，讓我們一次只關注一個點，思維負擔更小。且先寫測試可以幫助我們去思考需求，並提前澄清需求細節，而不是代碼寫到一半才發現不明確的需求。
但是我還是不太懂，我的困惑是:
如何做任務分解？第一步如何開始，實踐經歷較少，腦袋中有點小空白。
通過其他課程與軟工實踐的配合學習、實踐。我了解到了三種任務分解方法：類比方法、自頂向下、自底向上。以及在軟件測試中還有驅動模塊、樁模塊這兩種輔助模塊來配合漸增式集成測試。
在實踐中我們多采用自底向上的組裝方法來進行產品結構設計、任務分解等；也有參考過往屆優秀小組的經驗，結構設計或者任務分解方式、結果，我覺得這可能算是類比方法吧。個人覺得第一步最重要的是要明確自己要做什么、能做到什么。
以下經驗摘自個人作業2評論區：
ranh941：
接到任務后，第一步是理解任務，這個任務是做什么，你的理解與你的上級的理解是否一致，這個很重要。你需要主動去跟上級溝通，溝通之前需要把你要溝通的材料准備好，比如你的疑問、你對任務的理解、你也許要做的嘗試，同時需要注意到任務的截至時間；
第二步則是初步分解任務，按照自己的理解將任務拆分，按技術難點或者按業務邏輯，再根據任務時間倒排你拆分的子任務，再將拆解的結果主動報告給你的上級，同時自己也按拆解的任務表推進任務；
第三步則是按照拆解后的任務表推進任務的執行，在執行的過程也可以對已經拆分的任務再進行調整，這都是合理的。
- 問題5
《構建之法》第六章為我們介紹了敏捷流程。試問在軟件開發行業中，敏捷開發的可行性高低如何？應該更適合配合默契，經驗豐富的程序員才對？（采用敏捷開發，開發團隊的人員素質要求比較高。敏捷開發的首要任務是快速，目前提出的"全棧軟件工程師"，它要求軟件開發人員在開發的各方面：從需求，設計，編碼，測試一直到部署都要求是行家里手，可以減少因彼此溝通帶來的時耗，這才能保證他在一個Sprint中能獨立完成產品中某個特定的任務。顯然這樣的軟件開發人員的素質一定要求很高的，而在軟件開發行業中，人員流動率高，新手多的情況下，要做到這一點似乎是比較困難的。 這應當是敏捷開發的缺點之一。）
當時提出這一問題主要還是覺得自己能力不足，到了結對或者團隊項目中會拖后腿，跟不上節奏（在github實訓那天確實發生過）。現在的體會就是：素質有高低對比，能力有不足之處是必然的，不能因為自己不會做什么什么就害怕、完全不去做某事。體現在計算機專業就是：不能因為自己不會一個技術，就不敢去學習、不敢去編程（好像在哪里看到這個說法，忘記出處了）。
今后不管處在什么領域，遇到不擅長、不會的事物的情況一定很多，且肯定是有沒法逃避掉的工作等，此時，養成主動學習、終身學習的習慣才是解決問題的關鍵。
做中學
5個階段中，每個階段收獲最大的知識或能力是什么？
-
需求
需求分析階段需要定義一個用戶場景，關鍵不在於設計者本身想要做什么，而在於用戶想要什么；生活或工作中的某一環節遇到了什么困難；現在有怎樣的解決方案、效果如何；我們的軟件產品要提供怎樣的解決方案以、預期結果如何。還有做用戶故事分析時，時間地點人物等關鍵信息要盡可能明確，不要太寬泛隨意或者模糊，這樣對后續設計參考有幫助。 -
設計
自底向上的方法，問題4中有提到了。將我們離散的功能需求一一列出，看看哪些最小子模塊可以結合在一個模塊/界面里，或者有無冗余可刪去的，最終逐層向上組裝，完成功能模塊層次的設計；
還有學到了就是數據庫設計階段一定要提前想象想象實現階段可能會遇到的坑，多閱讀閱讀所選用技術、平台的文檔，看看是不是有些數據難以獲取、微信官方接口如何使用等，否則后期會挺頭疼，要返回去做改動；后端某處做出改動之后，要注意接口文檔保持一致性（以及通知隊內所有人）。 -
實現
收獲最大的就是vue語言的編寫鍛煉，采用UniApp+UView（基於Vue）來編寫了小程序前端，完成了前期的界面實現與后期的接口對接以及修復缺陷工作,熟悉了vue中的生命周期、路由跳轉、引用、緩存等基礎。還有問題2與問題3中提到過的，時間管理與分工協作溝通能力得到了鍛煉。其次，掌握了teambition的使用。 -
測試
鍛煉了單元測試與自動化測試工具（前端：Selenium IDE）的使用，應用了軟件質量與測試課程里的小部分知識和技能，收獲了黑盒測試、系統測試（壓力與性能測試）等經驗。以及鍛煉了通過真機線上測試，發現並復現bug，調試並找到問題根源所在的能力。 -
發布
學到了：微信小程序發布前夕，涉及到用戶隱私獲取、用戶發布文字、圖像、視頻等信息、商家資質等功能的政策一定要提前了解，不能等要發布了才去研究；可以提早deadline數天嘗試提交審核並發布線上版本，這樣出現意外問題可以及時解決，對用戶體驗調查也有利。
理解與心得
結合自己在個人項目/結對編程/團隊項目的經歷，談談自己的理解或心得
個人項目
部分語句摘自個人作業總結
- 作業開始的前幾天就實現了題目的輸出正確性要求，但代碼跑得很慢，為了優化性能，做了很多有用或無用的嘗試，深感最開始的設計中，選取簡單與效率兼備的解決之道很重要。后來在評論區老師的指點下，認識到了自己的不足（濫用API），也對代碼進行了改進，感想就是個人作業可以提前截止日幾天提交，讓老師助教多來點評點評，發現不足之處，這樣在最終提交前還有時間進行改進。
- 自動化的單元測試雖方便，但編寫代碼時候接口的設計還是會很頭疼，這又涉及到最開始的需求分析、設計上了，即一開始決定數據結構、參數如何傳遞時就要考慮好之后的擴展性，或直接從編寫單元測試開始。不然一直返工、改來改去很痛苦。
- 嚴謹是一件非常重要的事情，即使是字符統計中的\r\n，有效行統計中的空行判斷等小細節也是幾經思考，嘗試了好幾種處理方法才得到了最終的代碼。
- 個人作業最終得到了80多的分數，在正確性方面扣掉了，可能是正則表達式寫的不夠完善，沒有考慮到所有的可能情況，因此在一些隨機量大的測試樣例中，結果沒有全對。心得就是：黑盒測試還是不要做的太草率了，可以參考軟件質量和測試課程中的等價類划分法、邊界值分析法等，簡單應用到這里，且要多思考特殊情況。既鍛煉了測試能力又能提高正確率。
結對編程
部分語句摘自結對作業總結
- 結對第一次作業，原型設計：結對編程，潛藏於每個環節中的“溝通”這一動作，相較於個人作業要花費更多的時間成本，但以此換來的是整體效率上的提升。兩個人互相盯着，一有問題就馬上指出，幫忙修改，比預想的更快完成了，因此認為這個交換是值得的。
- 結對第二次作業，網站實現：遇到困難多查開發手冊、開發者社區；遇到無法逾越的困難多求助別人，互幫互助，自己死磕效率不高。因此兩人結對，在git上可能會遇到一些沖突解決有關的小問題，但開發上的問題就好解決了。有些東西就是自己打死都做不出來，隊友用同樣的時間一下就完成了；遇到了坑、bug，兩個人可以從不同的方向嘗試解決它，總會成功一種的，效率較高。一旦解決了坑，那么心態就會比自己一個人死磕要好點。
團隊項目
項目各階段歷程的心得體會在本博客“課程回顧與總結”的“做中學”模塊已經敘述了，接下來補充總體上的感想：
- 沒有必要只做文案與項目管理相關的工作，每位組員都可以盡量地參與到代碼編寫里去，不會就學一點。這樣更有參與感。
- 很多作業，實現過程和最終結果的重要程度是同樣的。因此有時不必糾結於成果的完美性，也要考量過程的嚴謹性與合理性、記錄與總結，留下可供參考的經驗。
- 最終分數其實只是你努力的一個附帶成果，真正的收獲都在過程中（鍛煉代碼能力等）。deadline趕不及就趕不及吧，沒必要做抄襲或者超時提交等事情，對團隊不好對自己也不好，最終老師和助教都不會太為難同學的（分數上）。
- 同上條提到的，不要做不誠信的事情。
個人技術總結
博客地址
概述
用戶在投訴的時候可以拍攝、多選上傳最多5張的照片，達到上限時，隱藏上傳按鈕；用戶可以預覽、刪除所選圖片，添加或刪除后的圖片數和預覽小圖要及時、正確地反映到界面上；最終圖片與投訴文字一起提交。難點：在已有組件的基礎上改進為自己想要的樣子。