這個作業的要求來自於：
第一章 概論：
這一章講述了關於電腦科學，軟體工程於電腦科學的關係，軟體的特徵，軟體工程的定義和組成部分。
第二章 個人技術和流程：
在閱讀開頭第一節「軟體是由多人合作完成的，不同人員的工作相互有依賴關係。例如，乙個人寫的模組被其他人寫得模組呼叫。軟體的很多錯誤都**於程式設計師對模組功能的誤解、疏忽或不了解模組的變化。如何能讓自己負責的模組功能定義盡量明確，模組內部的改變不會影響其他模組，而且模組的質量能得到穩定的、量化的保證？單元測試就是乙個很有效的解決方法。」再到後續的單元測試以及第二節「好的單元測試標準」後，其實不明白單元測試是什麼?以及單元測試的好處是什麼?想多了解這二方面內容。通過了解csdn裡有位博主寫了一篇文章「單元測試是什麼，有什麼好處
」【注釋1】。在了解了單元測試基本理解，再去看書中的知識，更容易理解了些。
第三章 軟體工程師的成長
在第三節中的「專和精的關係」中講到的乙個例子，街頭賣藝的單人樂隊，他們什麼都會一些，可以很快的演奏一些曲子，有與之對立的，是研習某一樂器的樂手。通過對比二者，得出了，會學多點**的人更勝出一些。但書中並沒有用到軟體工程中更實際詳細的例子，導致這個說法有些空洞。現在的軟體開發，尤其是**類，手機應用的開發，基本都是分前後 端開發的，一部分開發員負責前端，一部分開發員負責後端，那麼到底是要精通某前端還是後端部分，還是二者都去學習，基本掌握但不深入的掌握前後端呢？再看了「假如你想成為全棧工程師」【注釋2】的文章後，了解到了專和精其實還是要相對的，思維方式，個人能力，還有所處的工作環境，都會影響你對精和專的選擇。
第四章 二人合作：
在這一章中，前一部分講述的的是**的書寫規範，畢竟**是給人看，是給人閱讀的，容易理解的**更方便後期的管理和維護；後一部分講述的是更多的是**複審的步驟，方法。在第四節中的**複審中，看書中所寫的複審人都是要那些經驗豐富，熟悉該**的人，並且還要不止乙個人來書複審。個人覺得公司真的有這麼多時間通過人力來複審這些**嗎？畢竟看**也是很不容易的，有沒有可以通過乙個軟體工具就可以實現大部分的**複審，這樣可以省下很多的時間。
第五章 團隊和流程：
這一章主要講述了現代開發中各種團隊組合的模式，他們的優勢和劣勢以及開發的流程這二大部分。感觸較大的是團隊的模式，沒想到團隊的模式有這麼多種，那我便在想了，我們在開發的時候，應該組建什麼樣的團隊？還是根據具體軟體來組建團隊的模式？在團隊組合上，我覺得乙個理想的團隊，可以採用功能團隊模式和交響樂團模式兩者相結合的形式。因為每個模式都有其弊端，那為何不取其每乙個團隊模式最好的那一點，以最優的形式去組建一支個人理想的團隊。這些人之間沒有管理和被管理的關係。因為能力不同所以分工會很明確，互相溝通協作，效率會增高。然而，團隊的各個成員對團隊的目標，角色，產品都應有統一的理解，並且增加團隊的自我管理能力。
注釋：【注釋1】:
【注釋2】:
閱讀《構建之法》1 5章的感想
這個作業的要求來自於 第1章 概論 第一章前部分主要說了軟體 程式 軟體工程三者之間的關係，首先當寫了乙個程式擁有了一定的使用者隨之而來的需求這時候便需要出現乙個軟體去滿足各種功能，然後再擴充套件到乙個能保證服務質量的軟體服務，而軟體構建的過程又是十分複雜的，在保證軟體在修改過程中能不斷提高質量又保...
閱讀《構建之法》 1 5章
第一章 概論 第一章講述了軟體的特性和軟體工程解釋了什麼是軟體工程！問題 是什麼導致了軟體工程的出現。又是什麼推動了它的發展？第二章 個人技術和流程 第二章寫的是程式的測試流程和個人開發流程 問題 怎樣提高個人能力？第三章 軟體工程師的成長 問題 在軟體工程師成長過程中，怎樣平衡發展各個反面？注重全...
閱讀《構建之法》1 5章
第一章 概論 第一章講述了軟體的特性和軟體工程解釋了什麼是軟體工程！問題 是什麼導致了軟體工程的出現。又是什麼推動了它的發展？第二章 個人技術和流程 第二章寫的是程式的測試流程和個人開發流程 問題 怎樣提高個人能力？第三章 軟體工程師的成長 問題 在軟體工程師成長過程中，怎樣平衡發展各個反面？注重全...