第一章裡算是給軟體工程給個定義，也給了幾個公式，像 軟體=程式+軟體工程 等。做到符合使用者需求的軟體，在預計時間內發布「足夠好」的軟體，展現所開發的軟體是可維護，可持續發展的。總的來說，是創造好的軟體。
說幾點自己感覺感觸較大的方面吧。
「穩定，一致的交付時間是衡量乙個員工能力的重要方面。」我一直以為在規定的時間內交的越早就是能力越強，在書裡舉出的ai和bob例子裡打破了我的這種觀點，在給出的多個任務時交任務時，有「穩定」的交付時間，這算是更優秀一些。想要穩定，就得有非常紮實的基本功和一些經驗，這樣面對各種各樣的任務時，能做到不慌亂，按著節奏走，最後達到「穩定」的狀態。
知道乙個專案的團隊合作，但是聽都沒聽說過第四章講的「兩人合作」，這應該算是乙個小團隊吧，在結對程式設計裡我也有很多疑問，比如習慣乙個人寫，兩個人是不是浪費等問題，就像是我們自己寫作業，很難看出來**出錯，其他人卻很容易挑出來，我們看別人的作業也是如此。兩個人可以減少**錯誤量，也可以提高**的質量，相互提供經驗，分享知識，是一件很好的事。後面還寫到了兩人合作的不同階段和技巧，看著挺羨慕的，不知道自己什麼時候可以有個可以互相融合，互相影響，互相理解的**搭檔。
團隊合作。這個算是上一章「兩人合作」的深入吧。主要講了團隊協作的模式流程，各種流程的利弊。在團隊模式中，我更喜歡功能團隊模式，同事能力不同，平等協作，共同完成乙個功能。其他的模式，有的人少，有的嚴肅，有的散亂。瀑布模型，這算是最開始的程式設計模式，比較「硬」，在最初就確定好需求分析後對於以後的程式設計就會有乙個明確的目標。但是資訊變化迅速，這種模式變得不再適用，各種變形也各有優缺點。這章總的來說：團隊跟個人的關係：團隊是由個人組成的，個人離不開團隊，團隊又依賴於個人。
《構建之法》1 5章讀後感
在第一章中所述的與軟體工程相關的學科有除計算機學科外還有管理學，系統工程，工業設計等9門學科，這是不是意味著我們在學完計算機這門學科之後還要學習這些其他的另外9門學科呢？我知道能夠學完這幾門學科固然是好的，但我們如何能夠在只有計算機工程這門學科下更好的理解與學習軟體工程呢？在第二章中 你的rp是由你...
《構建之法》1 2 3章讀後感
第一章 看了大概了解軟體從乙個想法到最終成品的乙個過程。軟體先是由乙個想法引出的，有那個想法，你需要乙個工具去做什麼，然後根據自己想要的功能大概做乙個能實現基本功能的軟體，再對客戶提出的要求進行完善，實現了功能後對軟體進行維護。還有就是做的軟體要符合客戶的要求，而不是只根據自己的想法去做，要滿足大部...
《構建之法》8 9 10章讀後感
第八章 需求分析 這一章主要介紹軟體需求的型別 利益相關者，獲取使用者需求分析的常用方法與步驟 競爭性需求分析的框架nabcd,四象限方法以及專案計畫和估計的技術。需求分析是決定乙個軟體的使用範圍，只有乙個符合大眾需求的軟體，才能獲得收益。這時需求分析就顯得尤為重要。軟體需求分為以下幾個步驟 1.獲...