阿金的軟工實踐總結&個人技術部落格

這個作業屬于哪個課程	2021春軟體工程實踐|W班(福州大學)
這個作業要求在哪裡	軟體工程實踐總結&個人技術部落格
這個作業的目标	1.課程回顧與總結 2.個人技術總結
其他參考文獻	Mybatis的核心對象及運作流程 mybatis MyBatis 教程
目錄 課程回顧與總結 以前提問題的部落格連結:軟工實踐寒假作業2/2。 一學期後的問題認知 問題一、僅在必要時，才使用“類”？ 問題二、老闆驅動的流程（Boss-Driven Process）引發的思考 問題三、使用者調查問卷如何獲得正确的需求？ 問題四、PM的盛行會導緻産品跟不上潮流或者因為過多的調研而導緻在一項領域的占領落于下風嗎？ 問題五、對于順序執行的代碼段也有多種組合嗎？ 實踐中學習知識點 需求階段 設計階段 實踐階段 測試階段 釋出階段階段 在個人項目/結對程式設計/團隊項目的心得 個人項目 結對程式設計 團隊項目 個人技術總結 菜狗阿金技術總結部落格連結 概述：在準備篇中為自己定制的學習路線其實都有在學習，因為團隊作業也是做app端的，是以組裡的大佬在我有不懂的地方我會去詢問他。在團隊開發中，我負責java spring boot寫後端接口工作，而這個工作對于我準備篇的技術也有幫助，他讓我明白了，android可以調用spring boot 寫的接口，這樣，android寫一些網絡程式設計與前端界面足以。一學期過去了，我覺得收獲頗豐，在技術總結中的mybatis操作更讓我得心應手。

• 問題出處：4.3.4如何處理C++中的類中提到，隻有在必要的情況下才使用類。
• 自我認知：在c++的學習當中，類是作為一個很重要的知識點進行學習，上課寫程式老師也是盡量讓我們用類進行書寫。根據《建構之法》，c++課程對類的教學投入那麼多時間是否必要，而且類與結構體相似，書中也送出能用結構體就不要使用類，是書過于片面還是我的認知有誤。
• 尋求解答：類封裝很多時候都是為了安全。C++語言中定義一個函數，那麼在其他檔案中(假定你有很多.c檔案)定義的函數是可以通路的。除非把函數定義成static。有了類，隻要把函數改成private，那麼該函數就隻有自己可以通路了，其他檔案都通路不了。相當于把自己寫的函數保護起來了。類還有作用就是繼承。比如汽車和火車可以同時繼承于車。這樣可以使程式的結構很清晰 至于其他的，類中屬性也是很強大的存在。get和set方法等。一個private變量通過get和set方法可以保證其他類可以用該變量有可以保護該變量不被非法通路。
• 目前認知：必要時才用類封裝對我來說還是不太能了解，在一學期的軟工實踐中，我無時不刻都在使用類，在spring boot 架構中對類的使用可是不用類舉步維艱，是以我覺得這裡說的太過絕對，還有待商榷。

• 問題出處：5.3開發流程
• 自我認知：私以為老闆驅動的流程不算是一種開發流程，開發流程應該是從需求開始，從程式釋出結束。而老闆隻能算是旁觀者，特殊的使用者，通過老闆的要求進行程式的推進，但推進流程依然按照正常的步驟進行。
• 尋求解答：當軟體訂單的獲得不是主要靠技術實力，而是靠個人關系，或者暗箱操作的時候，老闆的能力決定了一個團隊是否能獲得訂單，既然軟體的具體功能并不重要（或者哪個團隊做水準都差不多），那麼老闆說做什麼就做什麼。但這與開發流程是一個事情嗎？抱有疑問
• 目前認知：在經受社會摧殘後，有一個個人能力出衆的老闆确實很重要，雖然不太符合開發流程，但是訂單什麼的由老闆擷取，說明老闆也有很強的個人實力，跟着老闆做軟體流程也不一定會失敗，當然在某些情況下有自己的看法也可以跟老闆提出來，以尋求最優解答。

• 問題出處：8.3 擷取使用者需求——使用者調查
• 自我認知：這種方法是指向使用者提供事先規定好的問題，讓使用者回答。但是，這種情況下使用者一般不會專心或者說符合自己内心想法地填寫問卷，一般都是随意填寫，随便選擇。如此收集到的使用者需求如何提取出重要的資訊，篩選掉雜亂問卷。縱然依照《建構之法》裡所說的設計問卷，但還是無法引導使用者來正确表達自己内心的需求。
• 尋求解答：明确調查目的和内容，問卷設計應該以此為基礎；明确針對人群，問卷設計的語言措辭選擇得當；在問卷設計的時候，就應該考慮資料統計和分析是否易于操作；問題數量合理化、邏輯化，規範化。
• 目前認知：在項目開始階段，我們的軟工實踐團隊作業也進行了使用者調查問卷，鎖定了大學城的女生群體。當時我們男生還是會認為這個軟體可能需求不是那麼大，但是在結束後，有一些使用者要我們改進算法，更新軟體，我就知道，當時的問卷沒有錯，這個軟體有市場，有需求。是以在問卷設計之初，就要有足夠大的基數，針對點要明确，這樣得到的結果一般不會偏離大方向。

• 問題出處：9.3 PM做開發和測試之外的所有事情
• 自我認知：目前軟體更新疊代過快，一個新的領域出現到一家獨大不過數月之短。若一個PM調研時間過長，讨論過久，是否會錯過該軟體釋出的最佳時間，導緻在其他擁有巨大使用者的公司的競争下銷聲匿迹。例如飛信與微信的競争，飛信“灰飛煙滅”，微信長盛不衰。
• 尋求解答：随着産業的發展，軟體應用的深度和廣度、軟體的複雜度、軟體團隊的複雜度都極大地提高了，PM起到溝通、交換、影響、潤滑、讨價還價的作用————就像商業社會的金錢一樣。
• 目前認知：PM的重要性在這次團隊作業中顯現的淋漓盡緻。抓住痛點，把握大方向。這次的軟工實踐正因為有我們的目光長遠的pm我們才會在這個outfits軟體上堅持下來。而且，縱觀網際網路，後來居上的也不缺來着，在淘寶一家獨大時，拼多多悄然問世，現已成為一個龐然大物。正因為有拼多多的pm毒辣的目光，針對便宜的商品，消費較低的人群，才有拼多多的現在。

• 問題出處：在13.2.2中的代碼覆寫率測試中提到不同的代碼是否執行，有很多種組合。一行代碼被執行過，沒有出現問題，并不表明這一行代碼在所有可能條件的組合下都能正确無誤地運作。
• 自我認知：我所知道的代碼除了多線程之外，其他的一般是順序執行，即使有循環結構，也是一遍一遍順序執行下去，是以這裡所說的一行代碼有很多組合是不是有所誇大。
• 尋求解答：不知是我了解有誤還是問題太過淺顯，通過多種關鍵詞進行檢索找不到答案
• 目前認知：目前還是沒什麼認知，對這塊還是知識盲區，代碼的運作順序多種組合，是針對什麼而言？

• 在需求階段，主要還是對産品的分析，看想做的這個軟體有無閱聽人，能否實作，做成的效果會是什麼樣，要有一個未來的展望。在這個階段，我鍛煉了分析需求的能力，同時也編輯了大量文檔，對NABCD的掌握也更加熟悉。

• 在設計階段，我有負責了對資料庫的設計，以及對系統接口的設計。在這個階段，去熟悉了資料庫設計的通用規則，符合規範，同時對限制，範式等知識點進行了鞏固。之前因為設定外鍵導緻删除或者添加而不成功的現象也得到了解決。在系統接口設計時，同前端組長進行商讨，對接口規範也更加了解，學了spring boot的初級内容，以及對postman的簡單使用。

• 在實踐階段，學習了spring boot的使用，包括idea插件的了解，以及xshell的使用，在原本不會使用伺服器的我，學會了對linux的配置以及将項目打包到伺服器運作。

• 在測試階段，說實話，測試階段我參與的不多，主要還是寫完代碼的單元測試，以及對等價類劃分的黑盒測試。測試功能能否實作，因為我主要的需求就是能運作，且運作正确，不出bug，而不是代碼優化。

• 在釋出階段，這時候重要的就有代碼優化這個内容。此時學了spring boot的面向切面程式設計，然後把一些能夠複用的代碼提取出來，成為工具類，使代碼簡潔。同時，對于回報回來的bug進行修改與版本疊代。

• 了解：先掌握一些程式設計基礎，以防止在後面的作業中無立足之地。
• 心得：個人項目容易對部落格作業的要求産生誤解，導緻作業做錯，而且也沒有驗證正确性的機會，送出之後要麼去再次了解部落格，但人會被自己主觀印象影響，導緻發現不了什麼問題。而最後出成績，又會發現自己明明會做，隻是了解出了偏差，導緻滿盤皆輸。是以，個人作業要麼有其他人一起互相幫助，但互相幫助容易産生作業相似的情況；要麼隻能看命，了解對了那就得分，了解錯了就沒分。希望下一屆能有驗證正确性的機會，而不是一刀切，畢竟是作業，而不是考試。

• 了解：體驗配合與溝通能力，兩個人能完成，那對團隊來說也能完成。
• 心得：結對程式設計是我決定最合适的一個作業，他考驗個人的代碼能力，溝通能力，團隊榮譽感。在配合中産生摩擦，也能及時得到解決。同時，有人負責一邊，會覺得安心，沒有那種腹背受敵的感覺。而且對作業的了解，兩個人考驗互相交換意見，得到一個最好的解決方案，已完成一個優秀的軟工作業。

• 了解：體驗和去公司一般的團隊工作，提前适應社會的工作狀态。
• 心得：團隊項目6-10的人員安排挺合理的，但由于一些同學并沒有好的技術支援，而大佬也沒有時間去教導“菜鳥”，導緻一部分同學隻能去做文檔工作。是以我認為在這裡可以插入一個作業，已提高項目内各個同學對項目技術棧的初級掌握。再者是有的同學要參加考研，是以對項目的熱情不是那麼大，而作業的安排空隙幾乎沒有，導緻積極性更低，是以希望下一屆能有一點點時間放空一下自己，而不是被兩件事擠得滿滿當當，甚至是被一件事擠得滿滿當當。