軟體工程實踐總結

這個作業屬于哪個課程	<2021春軟體工程實踐S班>
這個作業要求在哪裡	<軟體工程實踐總結&個人技術部落格>
這個作業的目标	課程回顧與總結與個人技術總結
其他參考文獻	...

- 課程回顧與總結
  - 提問連結
  - 提問
  - 在項目的需求/設計/實作/測試/釋出階段（一共5個階段）中，每個階段收獲最大的知識或能力
- 個人技術總結

原提問部落格

一、在3.1中提到了關于團隊對個人的期望

大多數工程師都在團隊的環境中工作，怎麼樣才是一個合格，甚至優秀的隊員呢?前面提到了PSP ( Personal Software Process )，和它對應的有團隊的軟體流程TSP ( Team SoftwareProcess )，TSP對團隊成員也有要求:

1.交流:能有效地和其他隊員交流，從大的技術方向，到看似微小的問題。

2.說到做到:就像上面說的“按時傳遞”。

3.接受團隊賦予的角色并按角色要求工作:團隊要完成任務，有很多事情要做，是否能接受不同的任務并高品質完成?

4.全力投入團隊的活動:就像一些評審會議，代碼複審，都要全力以赴地參加，而不是遊離于團隊之外。

5.按照團隊流程的要求工作:團隊有自己的流程（見“團隊和流程”一章)，個人的能力即使很強，也要按照團隊制定的流程工作，而不要認為自己不受流程限制。

6.準備:在開會讨論之前，開始一個新功能之前，一個新項目之前，都要做好準備工作。

7.理性地工作:軟體開發有很多個人的、感情驅動的因素，但是一個成熟的團隊

成員必須從事實和資料出發，按照流程，理性地工作。很多人認為自己需要靈感和激情，才能為宏大的目标奮鬥，才能成為專業人士。著名的藝術家Chuck Close 說:我總覺得靈感是屬于業餘愛好者的。我們職業人士隻是每天持續工作。今天你繼續昨天的工作，明天你繼續今天的工作,最終你會有所成就。

那個人應該對團隊有期望嗎？還是說應該如何選擇适合自己的團隊？

經過一個一學期的軟體工程實踐，當初覺得選團隊和領隊關系很大，現在也有了一些新的體會，比如确切體會到了管理者的作用。第一次Github實戰，在組長青澀的上司之下，一頓手忙腳亂，中途遇到了各種問題，最後的結果也不盡如人意。經過後來幾次團隊作業，大家都有了成長，組長的管理能力也有了提升，一切也變得井井有條起來。

二、關于書中4.3.2提到goto

函數最好有單一的出口，為了達到這一目的，可以使用goto。隻要有助于程式邏輯的清晰展現，什麼方法都可以使用,包括goto

實際應用中，goto究竟适不适用？團隊會不會對這方面有所要求？

這裡隻有一條從實踐中得體會，跟着團隊的代碼規範走就得了。

三、書中6.3關于靈活的團隊

靈活對團隊的要求很簡單:自主管理( Self-managing )、自我組織（Self-organizing )、多功能型(Cross-functional )，但是這很難做到。

軟體項目的團隊各式各樣（請看“團隊和流程”一章)，假設一個團隊做得還不錯，現在要變成靈活流程，那團隊要做下面的改變:

1.自主管理:以前上司布置了任務，我們實作就可以了，現在要自己挑選任務;每次

Sprint結束之後，還要總結不足，提出改進，并且自己要實施這些改進。“自主管理”不等于“沒有管理”。

2．自我組織:以前做好自己的事情就好了，安心下班。現在每個人要聯合起來對項目負責，有人工作落後了還要幫助他改進，項目缺少某類資源還要自己頂上去。

3．多功能型:以前規格說明書由PM來寫，測試由測試人員來做，現在每個人都全面負責,自己搞定規格說明書，和别人溝通，同時自己搞定測試。

這裡提到了每個人要聯合起來對項目負責,落後還要幫忙改進。但是書中也提到過我們在團隊中要各司其職，如7.2.4。這沖突嗎？

“每個人要聯合起來對項目負責,落後還要幫忙改進”是靈活的團隊中的内容，而“各司其職”指的是一般的團隊，實際上我們在實踐中也是各司其職的，但是也有“落後還要幫忙改進”的情況。後來再次閱讀書本發現當初誤把靈活的團隊和一般團隊放在一起比較了。

四、在12.1.3中提到的了

長期使用之後，軟體會更好用麼?

在設計軟體界面時，我們的設計師經常會畫新功能的UI設計圖，來征求大家的意見。我注意到大部分設計都假設使用者是頭一次使用産品，

是以沒有任何積累的檔案、照片、處理過的圖像、曾經做過的選擇等資料。我同意第一印象很重要，但是當使用者已經是第N次使用你的産品時，你的UI能否為這些使用者提供友善呢?你的産品是下面的哪一種:

a．軟體用得越多，一樣難用

b．軟體用得越多，越發難用

c．軟體用得越多，越來越好用

軟體是否好用和硬體也是相關的，但硬體發展很快（摩爾定律），是以軟體開發的時候也要考慮硬體。

這abc三種情況是可能同時出現的，那麼開發者如何把握軟體功能的提升和對硬體的要求提升的平衡？

同一款軟體不斷更新，可能有人會覺得越來越好用，因為他的硬體性能強大，有人覺得越發難用，因為他可能用的是好幾年前的機器。

拿手機來說，app的大小增長簡直太可怕，幾年前還是十幾M或者幾十M，現在動辄幾G，有些應用因太大被使用者暫時抛棄。

我覺得軟體提升前要考慮目前裝置的持有分布，把握好使用者群體分布，利益最大化；

極端假設：社會上所有人都很有錢，裝置一直保持最新款，那軟體的提升就隻需要考慮軟體本身的功能性能了，完全不用考慮使用者的硬體是否支援，因為使用者的硬體一直是最好的。

五、書中16.3.0提到的改良式創新(Incremental Innovation)和颠覆式創新(Disruptive Innovation)

提到了個故事：

雅卡爾( Joseph Marie Jacquard ) 1752年出生于裡昂，一成年便在絲綢工坊打工，并且很快成為一個有創意的、技藝娴熟的工匠。

他的改革計劃在法國大革命期間多次中斷，但1805年一大批改革後改進後的半自動織機最終在法國運轉了起來。

新織機不但縮短了産品的成型時間,更重要的是減輕了勞動量，減少了工作人數。這必然引起大批勞工的恐慌和随之而來的抵制及破壞，

因為使用雅卡爾織布機後，原來需要六名勞工完成的工作現在隻需一名，這就意味着大批勞工的失業。雅卡爾多次受到人身攻擊，甚至有人對他以死相逼，

更嚴重的是，工坊裡的新型織機不斷被損壞和焚燒。盡管如此，革新的成果還是迅速遍及全國。1812年，整個法國已裝置了一萬一幹多台雅卡爾自動織布機。

颠覆式創新的影響這麼大，會不會對這種創新起到緻命影響？比如因人身攻擊之類被迫停止。有沒有辦法減小影響的同時改變社會？

查閱資料：

一旦颠覆性創新出現（它是市場上現有産品更為便宜、更為友善的替代品，它直接鎖定低端消費者或者産生全然一新的消費群體），現有企業便立馬癱瘓。

為此，他們采取的應對措施往往是轉向高端市場，而不是積極防禦這些新技術、固守低端市場，然而，颠覆性創新不斷發展進步，

一步步蠶食傳統企業的市場佔有率，最終取代傳統産品的統治地位。

我的想法和原先還是一樣，也認為蠶食是個好辦法，可以有效的減少沖突，但是需要付出時間代價；但是要是能更快的帶來變革，也一定有積極的影響吧。至于會不會對創新起到緻命影響，

如果那麼容易被擊敗，也就不能稱得上颠覆式創新了吧，我認為影響最多就是蟄伏一些時間，當然時間也可能很長。

需求階段：提升UML的相關能力

設計階段：提升了繪制ER圖與類圖相關能力

實作階段：學習了SSM架構整合開發

測試階段：學習了一些測試工具如JUnit、JMeter的使用

釋出階段：學會了在伺服器上部署Java web項目

在第一次作業“準備篇”中你為自己制定了學習路線，現在學習了怎麼樣了？你在團隊開發中是否擔任了開發角色，你在開發中解決了哪些技術問題？獲得了哪些技術進展？

學習路線已經中途轉彎了。。。本來是計劃學習前端知識的，結果後來在團隊時由于後端人員不足去學習後端了。在團隊中負責部分子產品的後端開發。在開發中解決了一些檔案上傳下載下傳問題。SSM整合開發能力獲得提升。

連結：

SSM架構實作附帶資訊的檔案上傳&下載下傳

概述：SSM架構實作附帶資訊的檔案上傳以及下載下傳的一些内容

作者：fujiangfer

出處：https://www.cnblogs.com/fu12138/

-------------------------------------------

個性簽名：沒有

如果覺得這篇文章對你有小小的幫助的話，記得在右下角點個“推薦”哦，部落客在此感謝！

萬水千山總是情，打賞一分行不行(っ•̀ω•́)っ✎⁾⁾！