第一章，概論
源程式就是一行行**，是建立在資料結構上的一些演算法。程式還要對資料進行操作，這些資料有些是靜態的有些是動態的。但是工程師要把這些資料構建為及其能懂的可執行**。構建不僅僅是cc和link命令，乙個複雜的酸鹼不但要有合理的軟體構架，軟體設計與實現，還要有各種檔案和資料來描述各個程式檔案之間的依賴關係，編譯引數，鏈結引數等等，這些都是軟體構建的過程。
軟體團隊要從需求分析開始，把合適的需求梳理出來，然後逐步開展後續工作，如設計（軟體架構），實現（寫資料結構和演算法），測試，到最後發布軟體。
構建管理，源**管理，軟體設計，軟體測試，專案管理相關的活動是軟體工程的核心部分。
軟體= 程式+軟體工程
軟體企業=軟體+商業模式
程式是基本功，但是在演算法和資料結構智商，軟體工程決定了軟體的質量；商業模式決定了乙個軟體企業的成敗。軟體從業人員和軟體企業的道德操守會極大地影響軟體使用者的利益。
軟體工程的開發階段---1.玩具階段2.業餘愛好階段3.探索階段4.成熟的產業階段
軟體工程是把系統的，有序的，可量化的方法應用到軟體的開發，運營和維護上的過程。軟體工程包括下列領域：軟體需求分析，軟體設計，軟體構建，軟體測試和軟體維護。軟體工程和下列的學科相關：電腦科學，計算機工程，管理學，數學，管理專案學，質量管理，軟體人體工學，系統工程，工業設計和使用者介面設計。
軟體是可以執行在設計算計及電子裝置中的指令和資料的有序集合。（系統軟體，應用軟體，惡意軟體）。
軟體的特殊性：1.複雜性2.不可見性3.易變性4.服從性5.非連續性
工程：創造性地運用科學原理，設計和實現建築，機器，裝置或者生產過程，或者是在實踐中使用乙個或多個上述實體，或者是實現這些實體的過程。
bug的多少直接衡量乙個軟體的開發效率，使用者滿意程度，可靠性，和維護性。
要求：1.研發出符合使用者需求的軟體，2.通過一定的軟體流程，在預計的時間內發布「足夠好」的軟體3.能證明所開發的軟體是可以維護和繼續發展的。
第二章，個人技術和流程
建立單元測試函式的主要步驟：1.設計資料2.使用被測試型別的功能3.比較實際結果合預期結果
好的單元測試標準：1.單元測試應該在最基本的功能/引數上驗證程式的正確性2.單元測試必須由最熟悉**的人來寫3.單元測試過後，機器狀態保持不變4.單元測試要快
5.單元測試應該產生可以重複6.獨立性--單元測試的執行/通過/失敗不依賴與別的測試，可以認為構造資料，以保持單元測試的獨立性7.單元測試可以應該覆蓋素有**路徑7.單元測試應該繼承到自動測試的框架中8.單元測試必須和產品**一起儲存和維護
回歸測試，可以理解為「回歸到以前不正常的狀態」，就是乙個模組或功能以前是正常的，但是在乙個新的構建中卻出現了問題，這就需要回歸測試來解決此類問題。單元測試就是回歸測試的基礎。
效能分析主要講的是通過一些測試**來觀察什麼地方耗費的時間較多，能不能用別的方法來減少時間的花費，從而完成程式的優化。
個人開發流程，通過對比大學生和一些軟體工程師在完成乙個相同任務時的資料，告訴我們不要花費過多的時間在編寫**上，需求分析和測試同樣重要 。
個人感受：
我以前的做法：花費太多的時間浪費在編寫**上面。
這樣不好的原因：需求分析可以更快更準確的確定要做什麼，應該怎樣做，測試可以減少更好的維護程式**，更快的找出錯誤進行修改。
解決辦法：在編寫程式之前，首先要做乙個需求分析，寫清楚需要，和實驗過程。在程式的過程當中，增加單元測試的數目。
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
構建之法閱讀筆記01
從第一章概論中提到，軟體工程要創作足夠好的軟體。而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開...