1. 程式人生 > >作業四 閱讀《構建之法》1-5章的感想

作業四 閱讀《構建之法》1-5章的感想

意見 麻煩 兼容 根據 cnblogs 事情 保持 註釋 第二章

這個作業的要求來自於:https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178


第一章 概論

這一章主要介紹了軟件工程的理論和知識點還有其特性、計算機科學的領域介紹和它與軟件工程的關系。

在讀到1.2.5節的時候,我看了這一段文字 “軟件行業也有一句著名的笑話:這不是缺陷,這是一個功能!(It‘s not a bug,It‘s a feature!)很多人認為有Bug就是質量不合格,沒有Bug就是質量完美,其實這也未必。我們大街上看到很多不同品牌的汽車;這些汽車出廠時都通過了各自的質量檢測,符合行業的質量標準。但是你問路人哪些車的“質量好”,很多人會告訴你有些車的質量大大好於另外一些車,那為什麽還有人買那些質量“不夠好”的汽車呢?對於某些顧客來說,某一類的汽車滿足了他們的需求,他們就會買。如果銷售人員不經市場調研向不合適的目標用戶推銷自己公司的汽車,最後銷量未必理想。有實際用處的同時又是完美的軟件,在世界上是不存在的。沒有實際用處的“完美”軟件也幾乎沒有,有人會說一個打印“Hello World!”的程序似乎可以成為“完美”,但是我們不知道這個程序能不能算作一個軟件。那市面上有這麽多不完美的產品,軟件團隊為什麽還要把這些不完美的軟件發布出來呢?為什麽不能等到它們完美之後再發布?”,有這個問題“怎麽定義一個完美的軟件,難道所有發布出來的產品都是毫無缺陷的嗎?”。

我查了資料,CSDN裏有位博主說道“不是所有的缺陷都要修改。讓所有人都滿意的軟件是不可能的。對於用戶體驗問題一定要全面客觀地評價。最終交付近乎完美的產品。”,根據我的實踐,我得到這些經驗—就好比如蘋果手機,現在新出iPhone XS Max,盡管價格已經賣到上萬,可是每次經過蘋果專賣店裏面都是擠滿了人,甚至要買新產品需要排隊等上半個小時到一兩個小時才可以購買。為何那麽多人趨之若鶩,難道ios系統毫無缺陷?其實不是的,作為iPhone使用者,ios系統還是有一些不夠人性化的地方。就好像現在新更新的ios12新安裝之後也會有不少問題,比如部分APP由於兼容問題出現加載圖片異常的問題,耗電異常,續航變短還有地圖無法定位導航,定位失效等問題。所以以後會有更多的版本ios13、ios14....每一個版本都是上一個版本的更新,完善,改進。在我看來,軟件的缺陷是永遠改不完的,正是不斷有用戶使用發現新的缺陷,軟件才能做到不斷地完善,這個產品才會越來越好。 但是我還是不太懂,我的困惑是既然有新的改進,那麽軟件工程師如何保證在新的改進上保持著原來軟件的完整性呢?


第二章 個人技術和流程

這一章主要介紹了單元測試、回歸測試、效能分析、個人軟件開發流程(PSP)。

在讀到2.1.1節的時候,小飛和阿超的對話引起了我的註意,阿超在回答小飛的問題時說 “也許因為他們沒有在一開始就寫單元測試,所以後來又很多小強要處理。很多調查顯示,在軟件開發後期發現的Bug,修復起來要花更多時間。”,那麽我有個疑問“是不是每一步只要有新的功能出來就要弄一個單元測試,像C語言中一個單元就指一個函數,Java裏一個單元就指一個類,如果是一個十分大的項目,有很多函數,有很多類,它不就需要許多個單元測試,這樣繁雜的工序,有方法可以提高單元測試的效率嗎?”

我查了資料,CSDN裏有位博主寫了一篇文章“如何通過測試替代(Test Doubles)合理隔離單元測試以提高單元測試效率[註釋1],裏面有提到使用測試替代技術隔離單元測試中對網絡系統、數據庫系統和文件系統的訪問以提高單元測試效率的方法。Test Doubles為滿足單元測試的要求,通過一定的方法和技巧,解脫單元測試對外界的依賴變得更有現實意義。良好的單元測試代碼會極大的改善軟件代碼的架構設計和幫助開發人員編寫可測試的代碼(Testable Code),提高軟件質量。測試替代技術就是這樣一種方式,它可以幫助單元測試人員擺脫對第三方系統的依賴,進而提高單元測試的隔離性和執行效率。 根據我的實踐,我平時寫c語言或java的時候,每寫完一個函數功能就運行一次,看看有沒有Bug,但是有時候有些Bug是邏輯上的,j就會很難顯示出來,要自己慢慢地想,通常這種情況我都是屏蔽掉某些語句,然後運行,一直運行下來哪條突然運行有誤就知道是這個語句有問題,但是這個過程通常都要花費不少時間。但是我還是不太懂,我的困惑是比如是不是每個函數和類盡管之前測試後沒有問題,只要往後需要修改一點都要重新測試?那為了不斷完善代碼,是不是要一直進行單元測試?


第三章 軟件工程師的成長

這一章主要介紹了軟件工程師個人能力的衡量與發展和其發展還有技能的反面。

在讀到3.2.2節的時候,我看到了有關於“職業成長”的內容: “史蒂芬·邁克康奈爾創立的公司也為員工提供了一套成長路徑。簡介如下。首先,一個軟件工程師需要具備一定的知識和能力。知識:邁克康奈爾把相關的軟件知識分為十大知識領域。能力:一個工程師對這些知識的掌握分為如下四個階段。入門;熟練;帶頭人;大師。其次,工程師有職業成長級別。邁克康奈爾把工程師分為8個級別,一個工程師要從一個級別升到另一個級別,需要在各方面達到一定的要求。”,那麽我有這個問題“人們都說如果一個軟件工程師不往上爬(也就是不升級),一直原地踏步做碼農,到一定年齡就會被淘汰,這個到底是為什麽?”。

我查了資料,CSDN裏有一篇標題為“程序員年齡大了真的會被時代淘汰?[註釋2]的文章,雖然不長但我覺得講出了我心中疑惑的答案。他說“俗話說老姜辣味大,老人經驗多,老程序員的長達幾十年經驗是年輕程序員短時間內所不能企及的,滿足現狀,忽視知識更新,與時代脫節這類的人才會被社會放棄,由此可以看出跟上社會腳步,定期進行知識的更新與交流是很有必要的。”根據我的實踐,我還是很認同這位博主說的話,其實淘汰的不是年齡而是技術,是知識。原地踏步得不到提升,於現在的社會狀態就是會被淘汰。就好像達爾文所說的適者生存,道理是一樣的,有一群準備吃樹葉的長頸鹿,開始時,每只長頸鹿都能吃到樹葉。可是後來,較矮的樹葉被吃完了。這時,那些脖子比較長的長頸鹿就因能吃到樹葉兒活下來了。人就像舉例裏所說的長頸鹿那樣,社會需要與時俱進的人才,社會在進步,可是我們人卻止步不前,終究會被淘汰。一個程序員如果不更新自己,就會被這個圈子淘汰。基於這個答案有點我又不太懂了,我的困惑是一個程序員要怎麽樣才能做到與時俱進呢?只是不斷學習就可以了嗎?


第四章 兩人合作

這一章主要介紹了代碼和其風格還有設計的規範,代碼復審,結對編程,兩個人合作的不同階段和技巧。

在讀到4.6.1節的時候,我看了一個表格,它列出了“影響他人的4種方式”,分別是“斷言:感情很強烈,適用於充分信任的同伴。語音,語調,肢體語言都能幫助傳遞強烈的信息。”、“橋梁:給雙方充分條件互相了解。”、“說服:有條理,建立在邏輯分析的基礎上。即使不能全部說服,對方也可能接受部分意見。”、“吸引:可以有效地傳遞信息,但是要註意信息的準確性。誇大的渲染會降低個人的可信度。”。看完這幾種影響他人的方式之後,我便有了疑惑,每個人的性格都不同,每一個人的影響他人的方式也都不同,那麽如果當某一部分出現不同意見的時候,肯定很麻煩,為何不能一個項目一人完成,一定需要一個項目團隊?

我查了資料,王梓木先生寫了一篇名為“企業中人與人之間最本質的關系是合作[註釋3]的文章,裏面提到“互聯網時代是信息高度對稱的,在這種情況下,英雄創新的時代快結束了,大眾創新的時代到來了,大眾創新體現的依然是一種合作文化。”根據我的實踐,我覺得很多事情可能一個人真的可以完成,但是完成的情況還有時間會與多人合作完成的相差很遠。比如一個人做一個模型或者拼一塊拼圖肯定比幾個人一起做一起拼用的時間更多。多人合作可能會有分歧,會出現不同的意見,但是也正因為有這種分歧的出現,這個項目才會越做越好,一個人的想法永遠困在那一個人身上,無法得到擴展的話,那麽這個項目開發出來效果肯定沒有一群人開發出來的好。但是我還是不太懂,我的困惑是當一個項目真的具有很大的分歧,意見怎麽也不能夠統一的時候要怎麽樣解決呢?互相說服嗎?但是如果兩個想法都很好要怎麽取舍?


第五章 團隊和流程

這一章主要介紹了軟件團隊的模式還有開發流程。

在讀到節5.2節的時候,我看了作者列舉出了好多個軟件團隊的模式,分別是“一窩蜂模式”、“主治醫師模式”、“明星模式”、“社區模式”、“業余劇團模式”、“秘密團隊”、“特工團隊”、“交響樂團模式”、“爵士樂模式”、“功能團隊模式”、“官僚模式”,那麽我有這個問題“在那麽多的團隊模式中,怎麽樣才能知道自己的團隊屬於哪個模式呢?”

我查了資料,百度有篇文章“軟件開發和團隊建設[註釋4],裏面提到“一支程序開發團隊之所以成立,是為了承擔並完成某項由任何個人都無法獨立完成的任務。因為只有團隊合作,才能將復雜的事情變得簡單,將簡單的事情變得容易,使做事的效率倍增,可以說,團隊合作正推動企業向簡單化、專業化、標準化的方向發展。不管怎樣只要是團隊中的每個人能做好自己的事情,並能不斷的和別人交流,那麽這個團隊就是成功的。”,這幾句話不僅說明了團隊對於軟件開發的重要性,並且解答了我心中的疑惑。的確,無論是處於哪一種模式的團隊,只要做到自己做好自己的事情並且能夠善於與隊員溝通就肯定能成功。每個團隊的模式是要根據大家的情況來定。以前學校也經常需要我們小組合作,做的最好的小組通常組員的參與度最高,只有大家齊心協力地做,團隊做出來的產品才會像大家所預期一般。但是我還是不太懂,我的困惑是模式是根據具體的小組情況來定,但是它是規定化的嗎?某個團隊定下了某個模式之後團隊模式還可以隨著具體情況更改嗎?


結語:

閱讀了前五章的內容之後,解答了我很多有關於軟件工程這一學科的疑惑,盡管又有了新的疑惑,但是對軟件工程這一專業的知識了解了更多一些。之前看有關於軟件工程的書都覺得很難讀下去,很多知識點都難以理解,但是這本書作者寫得十分生動形象,理解起來基本沒有問題,而且覺得很有趣。


註釋:

1、如何通過測試替代(Test Doubles)合理隔離單元測試以提高單元測試效率:https://blog.csdn.net/cxboyee/article/details/50516486

2、程序員年齡大了真的會被時代淘汰?:https://blog.csdn.net/keoAEIC/article/details/80326677

3、企業中人與人之間最本質的關系是合作:https://www.xzbu.com/3/view-7334047.htm

4、軟件開發和團隊建設:https://baijiahao.baidu.com/s?id=1605761291755616092&wfr=spider&for=pc

作業四 閱讀《構建之法》1-5章的感想