軟體開發是一種集體活動，其中必然面臨各成員間的協調、統一問題。銀行每天都要對各網點進行清算結賬，軟體開發也是一樣的，必須找到一種方法來衡量每天的工作，保證每天的工作能夠有效的持續下去，最終把軟體開發的過程變成一種內在的過程。這種方法就稱為每日構建或是持續整合。每日構建構建的過程是完全自動化的，通過預先定義好的指令，機器將按照指令順序執行完所有的構建步驟。它讓開發者可以每天進行系統整合，從而減少了開發過程中的整合問題。持續整合可以減少整合階段"捉蟲"消耗的時間，從而最終提高生產力。它使得絕大多數bug在引入的同一天就可以被發現。而且，由於一天之中發生變動的部分並不多，所以可以很快找到出錯的位置。對開發人員而言，每日構建帶來的好處就是簽入即更新。
每日構建雖然會花費一些額外的時間，但是比起最後除錯的成本來說，日構建成本是微不足道的。而且更為關鍵的是能夠引入日構建的制度，開發人員將會在日構建的制度下更加頻繁的協作，開發進度一目了然，軟體的質量也會更加的穩定。軟體開發是一項強調溝通和協作的活動，但是在日常的活動中，常常出現阻礙溝通的情況。日構建每一次的構建將會涉及到團隊中的所有成員，因此能促進成員的溝通。
在每日構建的驅動下，專案的進度將會變得非常的明顯。每一天的構建結果將會通過某個渠道發布出來，團隊和團隊的老闆可以看到軟體現在的樣子，專案的完成情況，出現的問題等等。這些資訊構成了軟體開發的基本資訊。不但可以清晰地描述出專案進度，也為管理人員安排計畫提供了基礎資料的支援。有了基本的量化資料，軟體開發才不是靠拍腦袋出成果的。
每日構建的最後乙個價值是提供了整合性。目前軟體開發中並沒有一種統一的管理軟體，未來似乎也很難做到，因為不同的軟體組織差異很大。在開發過程中，一些有價值的實踐被加入、整合到每日構建的過程中，在每日構建的推動下，這些優秀實踐很容易成為開發過程的一部分。
構建之法03
瀑布模型是將軟體生存週期的各項活動規定為按固定順序而連線的若干階段工作，形如瀑布流水，最終得到軟體產品。它在1970年由溫斯頓 羅伊斯 winston royce 提出，直到80年代早期，它一直是唯一被廣泛採用的軟體開發模型。本書中例出了瀑布模型的文件圖，但是鄙人並沒有看得很懂它的用意。搜尋一些關於...
構建之法03
在現實社會中，人們為了解決生活中的各種問題，需要借助於軟體。但，每個人的需求都有不同，軟體團隊通過以下幾個步驟來獲取人們的需求 1.獲取和引導需求 軟體團隊需要找到軟體得利益相關者，了解挖掘他們對軟體的需求，引導他們表達出真實需求。同時，需求還可以來自各種管理機構，還可以來自軟體企業本身，也可以來自...
構建之法閱讀筆記03
通過這幾天的閱讀，基本對本書又有了新的認識，讀完這本書是一回事，要想深入的理解又是另一回事。本書第一版出自2014年，當時軟體工程正在中國蓬勃發展，在此書出來之前大學裡的教材有些還是外國書籍的翻譯版本。豆瓣上對此書的介紹是 軟體工程牽涉的範圍很廣,同時也是一般院校的同學反映比較空洞乏味的課程。但是軟...