書中有提到一句名言「軟體=
資料結構
+演算法」但是，在真正進行軟體開發時，我們會發現：我們所需要的資料結構和演算法都是現成的，我們只要進行呼叫和實現就可以了。在我學習了本書的第一章後，我認識到了「軟體=程式
+軟體工程」，從此也可以擴充套件為「軟體企業=軟體
+商業模式」。
軟體從最初的乙個簡單的程式，擴充套件到乙個滿足各種功能的應用軟體，再到乙個能保證服務質量的軟體服務。軟體沒有最好，只有更好。乙個**的軟體需要不斷更新，就是為了補充之前開發時所沒有發現的一些bug
，對軟體進行不斷的完善，同時，客戶也會進行在軟體使用期間不斷提出一些要求需要對軟體進行完善，使軟體使用者能得到更好的使用體驗。
軟體最基礎的就是源**。他們是建立在資料結構上的一些演算法，有些是靜態的，有些是動態的。但光有**和資料是不夠的，工程師要將他們編譯成機器可讀懂的可執行**。構建不僅僅是cc
和link
命令，乙個複雜的軟體不但要有合理的結構、設計和實現，還要有各種檔案用以描述各個檔案之間的關係等等，這些都是軟體構建的過程。一些好的軟體即使功能和同類軟體沒有多大的區別，但在使用者體驗上卻要比同類軟體後很多。
乙個軟體團體的盈利方式有很多：
1.客戶直接買斷軟體；
2.先試用再交錢；
3.客戶可以免費使用，但必須遵守團體給出的約定；
4.有的送硬體，軟體免費；
5.有的送軟體，硬體收費；
等等。軟體開發分為不同的幾個階段：
1.玩具階段；
2.業餘愛好階段
3.探索階段；
4.成熟的產業階段；
乙個軟體擁有很多特殊性：
1.複雜性；
2.不可見性；
3.易變性；
4.服從性；
5.非連續性；
在我閱讀了本書的第五章後，我意識到了真正好的軟體不是靠個人能力就能完成得，必須要有乙個好的軟體團隊，團隊中每個人都得有自己的任務。團隊合作也分為好幾種模式，它們分別為主治醫師模式、明星模式、社群模式、業餘劇團模式、秘密團隊模式、**團隊、交響樂團模式、爵士樂模式、功能團隊模式、官僚模式等等。
乙個軟體開發團隊，總是要有一些方法的，如寫了再改模式、瀑布模型、瀑布模型的各種改版、統一流程、老闆驅動流程、漸進交付的流程、tsp
原則等等。
第一，合理的工作分配非常重要
，乙個好的軟體小組其管理者必須要將小組內每個成員的能力都要有深刻的認知，在每次專案工作分配時做到人盡其用，充分發揮小組內每個人的才能，使這個專案能更好更快的完成。
第二，經驗。十七章中有一篇《乙個程式猿的生命週期》的文章主人翁談到近幾年的工作經驗，那就是軟硬結合的優勢。對於這一點我表示非常贊同，而我想說的並不是這個優勢，而是得到這個經驗的過程，別人的經驗就是別人的經驗，我們只能拿來借鑑，而永不可能成為自己的。對於一種結論，結果怎麼樣並不是很重要，重要的是我們得出這個經驗的過程，我們所能獲得的最多的也是在得出這個結論的過程中，而這個對於局外人是永遠體會不到的。
第三，軟硬結合的優勢。就我們電腦科學與技術來說，其本身就是乙個應該軟硬結合的專業，不管事以後的發展，還是社會上的公司，其方向都會趨向軟硬體結合，因為只有這樣我們才能擁有市場，才能擁有客戶。
其實作為乙個當代的大學生，我們不管從事什麼職業，做什麼都應堅持做下去。有一句話說的好：成功的路上並不擁擠。
《構建之法》讀後感
前段時間，我自學了 構建之法 的1,5,17章，並產生了很多自身的體會。首先，在第一章中我大致了解了我可以在書中學到什麼，如何落實學習。1.1節通過三個簡短的對話，啟發我對什麼是程式，什麼是軟體，什麼是軟體工程，也了解到了乙個軟體不是簡簡單單就能說寫就寫的，還需要考慮各種因素，如人們的需求，功能的可...
構建之法讀後感
第一章 軟體工程。寫軟體就是碼 寫出來，組合語句和演算法，實現需要的功能。但是軟體的開發需要一定步驟，有團隊合作精神，經過需求分析明白客戶需求，要什麼功能，並完成軟體的概要設計，再進行討論並與客戶溝通。然後進行軟體設計，然後程式 編寫，軟體測試debug，體驗版，後續維護等等。這樣才是乙個專案。軟體...
《構建之法》讀後感
首先，這是一本全景式的書，會讓你更了解這個行業，能讓畢業生在對行業從陌生到熟悉的過程中，較少地感到驚訝和出乎意料，這是一本與現實接軌的教材。其次，這是一本最佳實踐式的書，涵蓋了科學 健康的軟體工程開展中的每個方面，介紹了種種方 但不是高高在上 綱領性的方 而是方 的最佳實踐，確實可用，拿來就用。第三...