閱讀《構建之法》1 5章的感想

2022-08-29 03:21:10 字數 2979 閱讀 5802

這個作業的要求來自於:

第1章 概論

第一章前部分主要說了軟體、程式、軟體工程三者之間的關係,首先當寫了乙個程式擁有了一定的使用者隨之而來的需求這時候便需要出現乙個軟體去滿足各種功能,然後再擴充套件到乙個能保證服務質量的軟體服務,而軟體構建的過程又是十分複雜的,在保證軟體在修改過程中能不斷提高質量又保持以前的質量,就需要進行軟體測試,乙個軟體是否實現它的價值這時候就需要從需求分析開始,把合適的需求梳理出來,再開展後續工作,到最後發布軟體,總的來說就是:軟體=程式+軟體工程 乙個擴充套件的推論是:軟體企業=軟體+商業模式。 

軟體開發包括四個階段:1.玩具階段 2.業餘愛好階段 3.探索階段 4.成熟的產業階段 

接下來讀者向我們介紹了什麼是軟體工程? 總的來說軟體工程是把系統的、可量化的方法應用到軟體的開發、運營和維護上的過程。包括下列領域:軟體需求分析、軟體設計、軟體構建、軟體測試和軟體維護。

看完了第一章我有乙個疑問就是:我們目前所學的專業知識是否與在外工作所需的知識技能是否匹配呢?

第2章 個人技術和流程

第二章前部分主要說單元測試,單元測試能有效解決自己負責的模組功能定義無法明確、模組內部改變影響其他模組、模組質量無法保證穩定的、量化的等一系列問題,可是怎樣才算乙個好的單元測試呢?首先單元測試應該在最基本的功能/引數上驗證程式的正確性,單元測試也必須由最熟悉**的人(程式的作者)來寫,單元測試過後,機器狀態保持不變,單元測試要快(乙個測試的執行時間是幾秒鐘,而不是幾分鐘),而且單元測試應該產生可重複,一致的結果,還有獨立性-單元測試的執行/通過/失敗不依賴於別的測試,可以人為構造資料,以保持單元測試的獨立性,還有單元測試應該覆蓋所有**路徑且整合到自動測試的框架中,並和產品**一起儲存和維護。

接下來就是講的是效能分析工具,如何能讓自己的程式跑得又快又好,一般的做法是先用抽樣的方法找到效能瓶頸所在,然後對特定的模組用**注入的方法進行詳細分析,接著**分析的結果就出來了,可以繼續進行「效能測試,分析改進,再效能測試」的流程,逐漸提高程式的效能和我們的程式設計水平,但是也要避免沒有做分析就過早地進行效能提高,如果我們不經分析就盲目優化也許會事倍功半。

看完了第二章我有乙個疑問就是:如果單元測試的結果是錯的,為什麼一定是程式出了問題?

第3章  軟體工程師的成長

這一章主要是講軟體工程師的成長,主要從個人能力的衡量和發展、軟體工程師的職業發展、技能的反面一共三個方面來講述軟體工程師的成長。

首先我們應該如何來衡量證明自己的能力呢?首先是成長,讀者認為:1.積累軟體開發相關知識,提公升技術技能。2.積累問題領域的知識和經驗。3.對通用的軟體設計思想和軟體工程思想的理解。4.提公升職業技能。5.實際成果。接著衡量軟體開發的工作量和質量,從以下四個方面:1.專案任務有多大。2.花了多少時間。3.質量如何。4.是否按時交付。然後是團隊對個人的期望:1.交流。2.說道做到。3.接受團隊賦予的角色並按角色要求工作。4.全力投入團隊的活動。5.按照團隊流程的要求工作。6.準備。7.理性的工作。

那麼軟體工程的職業是如何發展的呢? 首先考級之路,接下來是職業成長,然後是大公司版本,例如成為乙個高階工程師,最後是對自我的評估。

那麼什麼是技能的反面呢?就是乙個「不精通」的面試者的程式設計過程實際上就是乙個「解決問題」的過程。那麼我們該如何提高我們的技能呢?首先我們需要通過不斷的練習,把那些低層次的問題解決了,變成不用經過大腦的自動操作,然後才有時間和腦力來解決高層次的問題。

看完了第三章我有乙個疑問就是:在如今的時代,需要一位具備什麼職業素養的軟體工程師?

第4章 兩人合作

這一章一開始寫的是如何規範我們寫的**:1.**風格要規範。2.**設計要規範。 那麼**風格需要怎麼樣規範呢?首先**風格的原則是:簡明、易讀、無二義性(縮排、行寬、括號、斷行與空白的{}行 、分行、命名、下劃線、大小寫、注釋);那麼**設計要如何規範呢?最好遵守以下規定:1.函式。2.goto。3.錯誤處理。4.如何處理c++中的類。

接著講**複審,**複審的正確定義:看**是否在「**規範」的框架內正確地解決了問題,那麼**複審的形式是什麼呢?1.自我複審。2.同伴複審。3.團隊複審。而同伴複審是最基礎的複審手段。**複審的目的在於:1.找出**的錯誤。2.發現邏輯錯誤。3.發現演算法錯誤。4.發現潛在的錯誤和回歸性錯誤。5.發現可能需要改進的地方。6.教育(互相教育)開發人員,傳授經驗讓更多的成員熟悉專案各部分的**,同時熟悉和應用領域相關的實際知識。那麼怎麼樣是乙個簡單的**複審核查表,主要包括:概要部分、設計規範部分、**規範部分、具體規範部分、具體**部分、效能、可讀性、可測試性。

在我們以後的專案中,有著非常多的而且多變的專案需求,同時存在著工期、質量、和資源的矛盾,我們團隊成員各自的水平、目標也不一致。那麼我們如何來構建乙個和平友好高效的團隊呢?我覺得在乙個團隊中,每個人都有自己不同的想法和意見,這時如何能說服對方?我覺得我們雙方都需要意識到,問題早點出現要比晚點出現要好得很多,並且正確地給自己的搭檔給予反饋。

看完了第四章我有乙個疑問就是:為什麼要結對程式設計?我覺得單人程式設計也挺好的。

第5章 團隊和流程

這一章一開始寫的是非團隊和團隊。團隊是有一致的集體目標一起完成這個目標,乙個團隊的成員不一定要同時工作,而非團隊成員則想搬多少就搬多少,不想搬了就走人。團隊成員有各自的分工,互相依賴合作共同完成任務,而非團隊成員各自行動獨立吧任務完成,軟體團隊的模式有以下幾種:1.一窩蜂模式。2.主治醫生模式。3.明星模式。4.社群模式。5.業餘劇團模式。6.秘密團隊。7.**團隊。8.交響樂團模式。9.爵士樂模式。10.功能團隊模式。11.官僚模式。

接下來講的是開發流程。有以下幾種模式:1.寫了再改模式。2.瀑布模式。3.由瀑布模型的各種變形。4.統一流程。5.老闆驅動的流程。6.漸進交付的流程,mvp和mbp。7.tsp的原則。

看完了第五章我有乙個疑問就是:流程的目的是什麼呢?

參考文獻

技術人生的職場眾生相 – 十多年的經驗與心得   

現代軟體工程 課件 軟體工程師能力自我評價表》

閱讀《構建之法》1 5章的感想

這個作業的要求來自於 第一章 概論 這一章講述了關於電腦科學,軟體工程於電腦科學的關係,軟體的特徵,軟體工程的定義和組成部分。第二章 個人技術和流程 在閱讀開頭第一節 軟體是由多人合作完成的,不同人員的工作相互有依賴關係。例如,乙個人寫的模組被其他人寫得模組呼叫。軟體的很多錯誤都 於程式設計師對模組...

閱讀《構建之法》 1 5章

第一章 概論 第一章講述了軟體的特性和軟體工程解釋了什麼是軟體工程!問題 是什麼導致了軟體工程的出現。又是什麼推動了它的發展?第二章 個人技術和流程 第二章寫的是程式的測試流程和個人開發流程 問題 怎樣提高個人能力?第三章 軟體工程師的成長 問題 在軟體工程師成長過程中,怎樣平衡發展各個反面?注重全...

閱讀《構建之法》1 5章

第一章 概論 第一章講述了軟體的特性和軟體工程解釋了什麼是軟體工程!問題 是什麼導致了軟體工程的出現。又是什麼推動了它的發展?第二章 個人技術和流程 第二章寫的是程式的測試流程和個人開發流程 問題 怎樣提高個人能力?第三章 軟體工程師的成長 問題 在軟體工程師成長過程中,怎樣平衡發展各個反面?注重全...