第一章、敏捷實踐

1、敏捷聯盟宣言

• 個體和互動勝過過程和工具
• 可以工作的軟體勝過面面俱到的文件
• 客戶合作勝過合同談判
• 響應變化勝過遵循計劃

2、在給新的團隊成員傳授知識方面，最好的兩份文件是程式碼和團隊。

3、有許多的敏捷過程可供選擇：SCRUM,Crystal，特徵驅動軟體開發，自適應軟體開發，極限程式設計（XP）

第二章、極限程式設計概述

1、客戶作為團隊成員。

2、使用者素材。就是正在進行的關於需求談話的助記符。它是一個計劃工具，客戶可以使用它並根據它的優先順序和估算代價來安排實現該需求的時間。

3、短交付週期。

4、驗收測試，一般由自動化指令碼構成，不斷擴充驗收測試集合，並且已經通過測試的功能不允許遭到破壞。

5、結對程式設計、頻繁交換角色、頻繁交換伴侶。（感覺有點扯淡）

6、測試驅動開發。

7、集體所有權。沒有程式設計師對任何特定的模組或者技術單獨負責。

8、持續整合。（理解為專案始終可編譯通過？）

9、可持續的開發速度。XP的規則是不允許團隊加班工作（扯），在版本釋出前的一星期除外。

10、開放的工作空間。

11、計劃遊戲。計劃遊戲不是計劃著去遊戲，而是做計劃是個遊戲。本質是劃分業務人員和開發人員之間的職責，。業務人員決定特性的重要性，開發人員決定實現一個特性所花費的代價。

12、簡單的設計。考慮能夠工作的最簡單的事情。、

13、重構。XP團隊通過經常性的程式碼重構來扭轉這種退化。重構時在不改變程式碼行為的前提下，對其進行一些列小的改造，旨在改進系統結構的實踐活動。重構時我們每隔一個小時或半個小時就要去做的事情。

第五章、重構

1、每一個軟體模組都具有三項職責。第一職責是它執行起來所完成的功能。著也是該模組得以存在的原因。第二個職責是它要應對變化。幾乎所有的模組在他們的生命週期中都要變化，開發者有責任保證這種改變應該儘可能地簡單。一個難以改變的模組是拙劣的，即使能夠工作，也需要對它進行修正。第三個職責是要和閱讀它的人進行溝通。對該模組不熟悉的開發人員能夠比較容易地閱讀並理解它。一個無法進行溝通的模組也是拙劣的，同樣需要對它進行修正。

2、作者認為提取出函式所增加的可讀性是值得花費額外一些微小的效能開銷的。然而，也許那些少許的開銷存在於深深的內部迴圈中，這將會造成較大的效能損失。作者的建議是假設這種損失是可以忽略的，等待以後再去證明這種假設是錯誤的。、

第六章、一次程式設計實踐

1、如果在設計階段，想要設計的一個類不具有任何行為，可以先不考慮。如果我們去關注那些不僅僅只有setter和getter方法的物件的話，會更有效率。

第七章、什麼是敏捷設計

1、軟體專案的設計師一個抽象的概念。它和程式的概括形狀、結構、以及每一個模組、類和方法的詳細形狀和結構有關。可以使用不同的媒介去描繪它，但是它最終體現為原始碼。最後，原始碼就是設計。

第八章、單一職責原則（SRP）

就一個類而言，應該僅有一個引起它變化的原因。

1、為何把兩個職責分離到單獨的類中呢？因為每一個職責都是變化的一個軸線。當需求變化時，該變化會反映為類的職責變化。如果一個類承擔了多於一個的職責，那麼引起它變化的原因就會有多個。變化的軸線僅當變化實際發生時才具有真正的意義。如果沒有徵兆，那麼去應用SRP，或者任何其他原則都是不明智的。

2、什麼是職責？在SRP中，把職責定義為“變化的原因”。

第九章、開放-封閉原則（OCP）

軟體實體（類，模組，函式等等）應該是可以擴充套件的，但是不可修改的。

1、對於擴充套件是開放的

模組的行為是可以擴充套件的。當應用的需求改變時，我們可以對模組進行擴充套件，使其具有滿足那些改變的新行為。換句話說，我們可以改變模組的功能。

2、對於更改是關閉的

對模組的行為進行擴充套件時，不必改動模組的原始碼或二進位制程式碼。模組的二進位制可執行版本，無論是可連結的庫，dll或者java的.jar檔案，都無需改動。

3、無論模組是多麼的“封閉”，都會存在一些對之封閉的變化。沒有對於所有的情況都貼切的模型。設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。必須猜測出可能發生的變化種類，然後構造抽象來隔離那些變化。

4、開發人員應該僅僅對程式中呈現出頻繁變化的那些部分做出抽象。拒絕不成熟的抽象和抽象本身一樣重要。

第十章、Liskov替換原則

子型別必須能夠替換掉他們的基類

1、如果新派生類的建立會導致我們改變基類，這就常常意味著設計時有缺陷的。

2、正方形和矩形的關係在軟體設計當中可能沒那麼簡單。物件的行為方式才是軟體真正所關注的問題。LSP清楚地指出，OOD中IS-A關係是就行為方式而言的。

第十一章、依賴倒置原則

a.高層模組不應該依賴於底層模組。二者都應該依賴於抽象。

b.抽象不應該依賴於細節。細節應該依賴於抽象。

1、依賴倒置可以應用於任何存在一個類向另一個類發訊息的地方。

第十二章、介面隔離原則（ISP）

不應該強迫客戶依賴於它們不用的方法