構建之法閱讀體會其二
通過讀完這本書，我已經對軟體工程這門課程有了初步的認識，的確複雜且工作量大，所以要更加認真負責的學習，並且多多實踐，運用「做中學」的學習方法
我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意。即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。在團隊內部，最具有效果並富有效率的傳遞資訊的方法，就是面對面的交談。工作的軟體是首要的進度度量標準。敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持乙個長期的、恆定的開發速度。不斷地關注優秀的技能和好的設計會增強敏捷能力。簡單是最根本的。最好的構架、需求和設計出於自組織團隊。每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。
軟體工程所討論的是當**量巨大、當涉及人數眾多、當專案需求多變時所要解決的問題。而我們在學習時根本就沒有這樣的需求。200來行的小程式，沒有軟體工程思想，也能完成，甚至更快捷。
軟體工程作為實踐類課程，理論如何應用，只能以真實案例呈現 (如果需要規模，那就應該有規模)，而無法用形成上學的方式推演--否則就意味著工程可以自動化，無須人的創造性參與。但是僅僅靠課堂老師對模型、類圖、資料圖的概念的解釋，對於軟體工程意識的建立並沒有太大幫助，而這本構建之法之所以好就好在要求學生完成大量的**，讓親身的經驗證實軟體工程的手段是必要和有效的。除此以外，別無他法。
如果面對軟體工程書，明白的就是明白了，不明白的還是不明白。已經受過苦的人，有過相同經歷的，能會心一笑；沒吃過苦沒糟過罪的，仍然魯莽行事，
事後一拍大腿，"哎呀鄒欣已經說過這事兒啦，我當時怎麼沒明白呢，古人誠不我欺啊"。事實上，即使事後諸葛亮，也是亡羊補牢，尤未晚也。我們有多少知識是 本科的時候學了，畢業以後多年才發現，原來在某個意想不到的地方才能用到。與課本相印證，能告訴你，你的失敗並非偶然，你的境遇並不孤獨，未避免同樣的悲劇再次發生打下很好的基礎。
它還會告訴你，所經歷的痛苦，可以用更形式化的方法，或者"最佳實踐"得以解決。這比你自己另搞一套，閉門苦苦鑽研十年，一抬頭發現古人早完成了要好得多。沒有先前的經驗，固然不會讓我體驗這麼深刻，如果沒有讀到前人的總結，我們就不過是一次次重複失敗
而已。
《構建之法》閱讀筆記二
第二章閱讀筆記 軟體工程師的個人技術之一軟體測試 軟體測試在軟體開發流程中佔據非常重要的地位。單元測試 因為大多數軟體工程師都是團隊合作，所以其開發的模組其他人很有可能會用到，所以保證模組的正確性 完善性是非常重要的，所以就要進行單元測試來對模組的功能進行驗證，驗證要保證各種資料都能通過，對於特殊的...
《構建之法》閱讀筆記二
構建之法 第二章標題為 注重實效的途徑.本章主要著重在與作為一位軟工人,在實際的編寫 中應當用什麼樣的方式使得自己的 編寫可以達到最高效,編寫出的 可以更加強健.甚至可以讓這看起來很容易.首先作者指出了重複的危害.我們擅長於從以往的程式設計,學習中總結出屬於自己的知識庫.可是在我們使用這個知識庫編寫...
《構建之法》閱讀筆記二
現代軟體產業經過幾十年的發展，乙個軟體由乙個人單槍匹馬的完成已經很少見了，軟體都是在相互合作中完成的。而這勢必要看別人的 所以有乙個好的 規範和設計規範是很有必要的。規範分為兩部分 1.風格規範。主要是文字上的規定，看似表面文章，實際上非常重要。2.設計規範。牽涉到程式設計 模組之間的關係 設計模式...