這次個人閱讀選擇的書籍為《構建之法：現代軟體工程》（鄒欣 著）。我們這門課程也參考了很多這本書的結構、內容與方法，讀這本書，既是對學過知識的複習和細化，也是對以後課程的預習。
下面總結了幾個閱讀過程中理解有困難或疑問的point，有的是細節，有的是大的方法。然後在網上查詢學習了相關內容，與大家分享。
1. 第4章 兩人合作 —— 4.3 程式碼設計規範 —— 4.3.3 錯誤處理
此處提到了“斷言”的概念，但著墨不多，介紹簡略。
那麼問題來了，挖掘機……不是，斷言是什麼？
編寫程式碼時，如果程式設計師相信在程式中的某個特定點某表示式值（布林式）為真，可將其標為斷言（assert）。
舉個栗子：
public class AssertionDemo{
public static void main(String[]args){
int i; int sum=0;
for(i=0;i<10;i++){ sum+=i; }
assert i==10;
assert sum>10&&sum<5*10:"sum is "+sum;
}
}
上述程式中語句assert i==10斷言i的值為10，如果i的值不為10將丟擲AssertionError異常。語句assert sum>10&&sum<5*10:"sum is "+sum斷言sum<5*10，如果為false，將丟擲帶有訊息"sum is "+sum的AssertionError異常。
如果肯定某件事一定要發生，則可以使用斷言；如果這件事有別的可能，則應用if……else處理。
由於可以在任何時候啟用和禁用斷言驗證，因此可以在測試時啟用斷言，而在部署時禁用斷言。同樣，程式投入執行後，終端使用者在遇到問題時可以重新起用斷言。
P.S. 此問題算個人知識的不足，之前不瞭解斷言的概念。
2. 第5章 團隊和流程 —— 5.3 開發流程 —— 5.3.2 瀑布模型
瀑布模型是將軟體生存週期的各項活動規定為按固定順序而連線的若干階段工作，形如瀑布流水，最終得到軟體產品。它在1970年由溫斯頓·羅伊斯（Winston Royce）提出，直到80年代早期，它一直是唯一被廣泛採用的軟體開發模型。
本書中例出了瀑布模型的文件圖，但是鄙人並沒有看得很懂它的用意。
搜尋一些關於瀑布模型的解釋後看到了這樣一句話：”瀑布模型的本質是‘一次通過’；它是一種文件驅動模型，在可執行產品交付之前，客戶只能通過文件來了解最終的產品會是什麼樣子。“
這才恍然大悟書中那個8種文件被各個過程生產、修改的含義。由於瀑布模型是線性的，在最終產品產生前，如何產生有用的文件指導開發、銜接兩個階段非常重要。
3. 第6章 敏捷流程 —— 6.5 敏捷的故事
這一小節中有一個圖表，對比了敏捷（Agile）、計劃驅動（Plan-driven）、形式化的開發方法（Formal Method）的適用範圍。裡面提到的形式化的開發方法，其基本步驟是怎樣的呢？為什麼它能有極高的可靠性呢？下面是一些關於形式化方法特點的說明，從中可以看出它能力的緣由。
形式化方法建立在嚴格的數學基礎上，其目標是希望能使系統具有較高的可信度和正確性，並能使系統具有良好的結構，使其易維護，關鍵是能較好地滿足使用者需求。“形式化方法”一詞雖然一直被廣泛地應用，但在不同程度上，因理解不同，使其具有了不同的含義。一般說來，形式化方法是指具有堅實數學基礎的方法，它是數學上的綜合、分析技術的應用，用於開發計算機控制的系統，經常有推理工具的支援，它可提供一個用於模型設計和分析的一個嚴格而有效的途徑。
形式符號系統具有一定的數學性質，所以它們非二義性的基礎在於其內在的數學結構。越是複雜的數學概念，越是建立在更原始的概念之上，如：集合、命題邏輯。這就是說，形式符號系統可以具有合適的解釋，並在理論上足以確保規範的一致性解釋。 形式規範是由一些精確的定義組成的，因為其符號系統的含義是明確定義的。相對地，若將英語作為交流媒體，將很難得到精確的規範。精確規範的直接益處在於：它能減少規範中的二義性和誤解釋的可能性（危險）。精確是形式化方法或形式符號系統的一個特徵，是產生無二義性規範的主要依據。另外，形式規範主要的語用益處在於：可以對形式規範進行較詳細的構造性檢查，因為對此規範中的具體內容的含義不會有爭議，有爭議的只是內容的完備性。換句話說，精確有助於確認和交流。 由於適當的形式機制的使用，使得規範的抽象性成為可能。抽象是人們處理複雜性的主要智力工具之一，而且通過忽視不感興趣的部分，從而有助於清晰性。各種形式符號系統對於精確、抽象地表達概念具有各自不同的能力，但它們均可用於嚴密地描述概念，更重要的是，它們比自然語言的描述更嚴密、更精確、更抽象。一般地，形式系統（框架）使得表示一個規範與其相應程式之間的對映成為可能。 形式規範有一個很有價值的特性：可操縱性。這就是說，可以在明確定義的規則的指導下，分析規範或或對形式規範進行變換。利用形式規範的可操縱性可以證明規範的一致性；可以推匯出關於此規範的一些重要結果；還可以驗證規範的實現過程，至少可以驗證原始碼相對於其規範的正確性。更一般地說，有可能將不同級別規範間的驗證以及規範與程式間的驗證問題簡化為形式證明問題。這樣，形式化方法就可以提供程式對應其規範的非常高的可信度。所以，可操縱性也有助於確認，並且由這種特性可以得到進一步的抽象（推匯出的性質），同樣，也有助於使得規範更清晰。
4. 第6章 敏捷流程 —— 6.5 敏捷的故事
這一小節提到了幾種比較出名的敏捷開發方法論，如FDD、Scrum、XP、TDD。前三者在書中都有專門的介紹，但TDD，久聞其大名，到底是何許妙招？
簡單來說，就是不可執行/可執行/重構——這正是測試驅動開發的口號。
可想而知，測試驅動開發會極為有效地控制開發中的bug，但是這種先寫測試程式碼的方式可能讓開發人員有很大的不適應。學習適應TDD的成本會不會比它帶來的收益更高呢？這就有待我們在實踐中摸索了。
5. 第11章 軟體設計與實現 —— 11.2 開發階段的日常管理 —— 11.2.2 每日構建
這一小節中提到了每日構建的重要性，那麼，什麼是每日構建？
軟體開發是一種集體活動，其中必然面臨各成員間的協調、統一問題。銀行每天都要對各網點進行清算結賬，軟體開發也是一樣的，必須找到一種方法來衡量每天的工作，保證每天的工作能夠有效的持續下去，最終把軟體開發的過程變成一種內在的過程。這種方法就稱為每日構建或是持續整合。每日構建構建的過程是完全自動化的，通過預先定義好的指令，機器將按照指令順序執行完所有的構建步驟。它讓開發者可以每天進行系統整合，從而減少了開發過程中的整合問題。持續整合可以減少整合階段"捉蟲"消耗的時間，從而最終提高生產力。它使得絕大多數bug在引入的同一天就可以被發現。而且，由於一天之中發生變動的部分並不多，所以可以很快找到出錯的位置。對開發人員而言，每日構建帶來的好處就是簽入即更新。
每日構建雖然會花費一些額外的時間，但是比起最後除錯的成本來說，日構建成本是微不足道的。而且更為關鍵的是能夠引入日構建的制度，開發人員將會在日構建的制度下更加頻繁的協作，開發進度一目瞭然，軟體的質量也會更加的穩定。軟體開發是一項強調溝通和協作的活動，但是在日常的活動中，常常出現阻礙溝通的情況。日構建每一次的構建將會涉及到團隊中的所有成員，因此能促進成員的溝通。
在每日構建的驅動下，專案的進度將會變得非常的明顯。每一天的構建結果將會通過某個渠道釋出出來，團隊和團隊的老闆可以看到軟體現在的樣子，專案的完成情況，出現的問題等等。這些資訊構成了軟體開發的基本資訊。不但可以清晰地描述出專案進度，也為管理人員安排計劃提供了基礎資料的支援。有了基本的量化資料，軟體開發才不是靠拍腦袋出成果的。
每日構建的最後一個價值是提供了整合性。目前軟體開發中並沒有一種統一的管理軟體，未來似乎也很難做到，因為不同的軟體組織差異很大。在開發過程中，一些有價值的實踐被加入、整合到每日構建的過程中，在每日構建的推動下，這些優秀實踐很容易成為開發過程的一部分。
每日構建的工具有很多，但是最基礎、最廣泛的工具是Ant（http://ant.apache.org）。