軟體領域可以分為兩個方面：一方面是技藝創新的大爆發；另一方面是堅持不懈的工程工作，包括軟體的改善、維護和測試等，這一方面佔了90% - 95%的比例。
—— 瓦茨·漢弗雷 / 軟體工程的奠基人之一
對於我們做軟體的人來說，我覺得寫**的能力固然重要，但是專案開發中用到的專案管理和專案開展的方法等根據實踐總結出來的經驗和知識，是不可忽視的，有時候比專案更重要。這些部分的知識，恰恰很容易被大家輕視，它們大部分是實踐經驗，因而對於我們這樣的初學者來說，這些內容可能聽起來有些陌生，好像在講誰都會說的大道理，沒什麼用處。但當我們通過乙個學期的學期的學習之後，我們逐步積累起來的一點點專案經驗，遇到了這方面的問題，比如進度規劃的問題，設計的問題，團隊合作的問題，我們才會意識到這些知識雖然聽起來理所當然，但是需要在實際開發中使用，還是很需要一些經驗，費一些功夫的。
就像我們經常不注意或者不耐煩這些說明書的編寫，但是這是一種規範，使用者是不會去看你的**的，可你能給使用者呈現的除了軟體本身就是這些說明書，把該交代的內容交代清楚，既方便了使用者對軟體的理解與使用方便，又能讓他人體會到我們的設計原則，對我們以後的發展，對下次軟體的設計大有幫助。
還有就是軟體人永遠記住使用者是第一位，我們做軟體是為了滿足使用者的需求，一定要始終記得使用者需要的是什麼，使用者第一步說我要用英文，那麼從開始到中間的傳遞各種資料到最後結束都要始終用英文，這才叫始終記住使用者的選擇。
大部分人之所以牴觸這些「所謂的軟體工程的知識」，很大部分的原因，就是不貼進我們的現實開發環境的的，而《構建之法》這本書的內容和普通的講述軟體工程的書的內容是無異的，但是通過具體的小例子和情景，就很有代入感，讓讀者更能理解這些「所謂的軟體工程的知識」
說明書的編寫，使用者是不會去看你的**的，可你能給使用者呈現的除了軟體本身就是這些說明書，把該交代的內容交代清楚，既方便了使用者對軟體的理解與使用方便，又能讓他人體會到我們的設計原則，所以軟體人不但要會寫**，還要學會寫文件。
uml圖形建模的重要性，建模的過程實際上就是整理思路的過程，可以幫助我們快速理解這個系統的需求，基本上建模完成，整個系統的構建也就出來了。
02《構建之法》閱讀筆記02
個人感受 過去我的做法 1 以前每個部分都是分開各做各的，做好自己的事情就好了 不需要管其他的。獨立開發，想做什麼做什麼，只要實現布置的任務就行。這樣做的缺陷 無法做到團隊快速開發，很難提公升速度。問題解決方法 1 要自己挑選任務 每次sprint結束之後，還要總結不足，提出改進，並且自己要實施這些...
構建之法閱讀筆記02
第二章的開頭就給我講出了單元測試的概念和效果，單元測試可以使自己父子的模組功能定義盡量明確，模組內部的不會影響其他模組，而且模組的質量能得到穩定的，量化的保證。還舉例了小飛寫單元測試的例子，讓我們隊建立單元測試主要步驟印象深刻，建立單元測試的主要步驟 1.設定資料 2.使用被測試型別的功能 3.比較...
構建之法閱讀筆記02
今天看了第六章敏捷流程，在裡面我看到了衝刺執行任務中的每日例會，在這裡身份的類似於主人暑假給我們布置的任務和發表部落格的要求，其中這裡面有三條內容，分別是我昨天做了什麼，今天做了什麼，在其中又遇到了什麼問題。這個寫問題只有在衝刺階段真正的做了，用心的去解決了，才會真的有收穫 相反這些流程也會流於形式...