軟件工程實踐總結

課程回顧與總結

提問鏈接

原提問博客

提問

一、在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年，整個法國已裝置了一萬一干多臺雅卡爾自動織布機。

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

查閱資料：

一旦顛覆性創新出現（它是市場上現有產品更為便宜、更為方便的替代品，它直接鎖定低端消費者或者產生全然一新的消費群體），現有企業便立馬癱瘓。
為此，他們采取的應對措施往往是轉向高端市場，而不是積極防御這些新技術、固守低端市場，然而，顛覆性創新不斷發展進步，
一步步蠶食傳統企業的市場份額，最終取代傳統產品的統治地位。

? 我的想法和原先還是一樣，也認為蠶食是個好辦法，可以有效的減少沖突，但是需要付出時間代價；但是要是能更快的帶來變革，也一定有積極的影響吧。至于會不會對創新起到致命影響，
? 如果那么容易被擊敗，也就不能稱得上顛覆式創新了吧，我認為影響最多就是蟄伏一些時間，當然時間也可能很長。

在項目的需求/設計/實現/測試/發布階段（一共5個階段）中，每個階段收獲最大的知識或能力

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

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

實現階段：學習了SSM框架整合開發

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

發布階段：學會了在服務器上部署Java web項目

個人技術總結

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

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

鏈接：

SSM框架實現附帶信息的文件上傳&下載

概述：SSM框架實現附帶信息的文件上傳以及下載的一些內容