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

時間 2019-11-13

標籤閱讀構建之法感想简体版

原文原文鏈接

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

第一章概論ios

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

在讀到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因爲兼容問題出現加載圖片異常的問題，耗電異常，續航變短還有地圖沒法定位導航，定位失效等問題。因此之後會有更多的版本ios1三、ios14....每個版本都是上一個版本的更新，完善，改進。在我看來，軟件的缺陷是永遠改不完的，正是不斷有用戶使用發現新的缺陷，軟件才能作到不斷地完善，這個產品纔會愈來愈好。可是我仍是不太懂，個人困惑是既然有新的改進，那麼軟件工程師如何保證在新的改進上保持着原來軟件的完整性呢？編程

第二章我的技術和流程網絡

這一章主要介紹了單元測試、迴歸測試、效能分析、我的軟件開發流程（PSP）。架構

在讀到2.1.1節的時候，小飛和阿超的對話引發了個人注意，阿超在回答小飛的問題時說「也許由於他們沒有在一開始就寫單元測試，因此後來又不少小強要處理。不少調查顯示，在軟件開發後期發現的Bug，修復起來要花更多時間。」，那麼我有個疑問「是否是每一步只要有新的功能出來就要弄一個單元測試，像C語言中一個單元就指一個函數，Java裏一個單元就指一個類，若是是一個十分大的項目，有不少函數，有不少類，它不就須要許多個單元測試，這樣繁雜的工序，有方法能夠提升單元測試的效率嗎？」ide

我查了資料，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]，裏面提到「一支程序開發團隊之因此成立，是爲了承擔並完成某項由任何我的都沒法獨立完成的任務。由於只有團隊合做，才能將複雜的事情變得簡單，將簡單的事情變得容易，使作事的效率倍增，能夠說，團隊合做正推進企業向簡單化、專業化、標準化的方向發展。無論怎樣只要是團隊中的每一個人能作好本身的事情，並能不斷的和別人交流，那麼這個團隊就是成功的。」，這幾句話不只說明了團隊對於軟件開發的重要性，而且解答了我心中的疑惑。的確，不管是處於哪種模式的團隊，只要作到本身作好本身的事情而且可以善於與隊員溝通就確定能成功。每一個團隊的模式是要根據你們的狀況來定。之前學校也常常須要咱們小組合做，作的最好的小組一般組員的參與度最高，只有你們齊心合力地作，團隊作出來的產品纔會像你們所預期通常。可是我仍是不太懂，個人困惑是模式是根據具體的小組狀況來定，可是它是規定化的嗎？某個團隊定下了某個模式以後團隊模式還能夠隨着具體狀況更改嗎？

結語：

閱讀了前五章的內容以後，解答了我不少有關於軟件工程這一學科的疑惑，儘管又有了新的疑惑，可是對軟件工程這一專業的知識瞭解了更多一些。以前看有關於軟件工程的書都以爲很難讀下去，不少知識點都難以理解，可是這本書做者寫得十分生動形象，理解起來基本沒有問題，並且以爲頗有趣。

註釋：

一、如何經過測試替代（Test Doubles）合理隔離單元測試以提升單元測試效率：http://www.javashuo.com/article/p-qddygvmy-nq.html

二、程序員年齡大了真的會被時代淘汰？：http://www.javashuo.com/article/p-ejcglyez-bz.html

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

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