構建之法讀後感1

2022-09-07 19:42:11 字數 860 閱讀 3067

構建之法一開始講了啟發我對什麼是程式,什麼是軟體,什麼是軟體工程。

1、自己曾經在是認為乙個軟體就是程式設計出來出來就行,能執行就好了。

但是這本書講了還需要考慮各種因素,如人們的需求,功能的可行性。

2、自己認為的團隊合作就是一起分不同的任務最後總結

《構建之法》第一章介紹了軟體工程的概念、理論、知識點和軟體工程和電腦科學的關係。具體來說是讓我認識到了以下幾個概念:源**管理,配置管理,質量保證,軟體測試,需求分析。程式理解,軟體維護,服務運營,合稱為軟體的生命週期。另外讀到"將軟體與程式分隔開來的就是使用者體驗 " 這個理念是不由的聯想到我的**,只能歸類到『程式』,哎~。軟體系統是把系統的、有序的、可量化的方法應用到軟體的開發、運營和維護的過程。包括:需求分析、設計、構建、測試和維護這幾個過程。鄒欣老師還通過紙飛機到商用飛機模擬說明了軟體開發的四個不同階段:玩具階段,業餘愛好階段,探索階段,成熟的產業階段。也得出:軟體=程式+軟體工程的結論。

《構建之法》第二章講的是個人的技術和流程,第二章首先看到的是讓我很找不到頭緒的,單元測試,不知道怎麼去測試,不知道測試有什意思。為什麼要測試,程式寫好了執行一下能執行一下不就行了,為什麼還要測試,還非讓**的作者去測試,真的麻煩,但是,看完之後覺得測試是很有必要的,個人理解為:單元測試結果的好壞,是檢測乙個程式的好壞的標準,是檢測乙個程式是否有隱藏的bug的標準。乙個好的標準的單元測試能找到程式執行快慢的原因,從而進行程式的提高。在這之後的回歸測試看的就不懂了,還有就是什麼抽樣,和**注入,真的很不懂,但是有一點看懂了,那就是**的寫法不一樣那源**中的乙個函式的呼叫的次數就會不一樣,從而導致呼叫的時間也就會不一樣。在這裡也理解到了效能測試的重要性。

以後我不知要學會做出來軟體而且還要學會讓他符合人們的需求和感受,還有在團隊中更加多的交流讓合作更加簡單。

構建之法讀後感 1

1 成功的變革不是完全自上而下或者自下而上,而是通過結合兩者的變革相關要素。2 如果我們不能預見到scrum轉型的結束狀態,便無法確定當前狀況和結束狀態之間所有的差距。3 變革與過去培訓的內容往往產生衝突,軟體開發人員很難在短時間適應這種變化,導致轉型的失敗。4 人進行改變的能力是有限的,因此企業進...

構建之法讀後感1

這個寒假老師要求我們讀 構建之法 並發表三篇讀書筆記。今天淺讀了一點構建之法開篇部分,原來老師上課給我們出的那個該死的三十道算術題的問題就是出自這本書,真晦氣。書裡提到軟體 程式 軟體工程,那軟體工程是什麼,看了半天,軟體工程是乙個過程,是把系統的 有序的 可量化的方法應用到軟體的開發運營和維護上的...

構建之法讀後感

書中有提到一句名言 軟體 資料結構 演算法 但是,在真正進行軟體開發時,我們會發現 我們所需要的資料結構和演算法都是現成的,我們只要進行呼叫和實現就可以了。在我學習了本書的第一章後,我認識到了 軟體 程式 軟體工程 從此也可以擴充套件為 軟體企業 軟體 商業模式 軟體從最初的乙個簡單的程式,擴充套件...