1、敏捷軟體開發宣言
個體和互動 勝過 過程和工具
可以工作的軟體 勝過 面面俱到的文件
客戶合作 勝過 合同談判
響應變化 勝過 遵循計畫
2、面相物件設計的原則
單一職責原則
開放-封閉原則
liskov替換原則
替換原則
依賴倒置原則
介面隔離原則
重用發布等價原則
共同封閉原則
無環依賴原則
穩定依賴原則
穩定抽象原則
3、極限程式設計實踐
最好的軟體開發人員都知道乙個秘密：美的東西比醜的東西建立起來更廉價，也更快捷。構建維護乙個美的軟體系統所花費的時間、金錢都要少於醜的系統。軟體開發新手往往不理解這一點。
軟體設計最精髓的東西：平衡。
設計是人的思維的一種動態活動，是設計者針對自己的問題的思索、權衡、折衷、選擇的過程。其中會出現很多在理想情況下不會出現的問題，對這些問題的處理水平才是真正的設計水平。
此外，本書中也講述了很多的設計模式，但是和很多其他講述模式的書不同的是，它更多的時候是在告訴你什麼時候不要去使用模式，去抵制模式的**，以免帶來不必要的複雜性。在對模式狂熱吹捧的今天，本書無疑是一劑糾偏良藥，可以讓你更加合理、有效地使用模式。
本書主要包含4部分內容，這些內容對於今天的軟體工程師都非常的重要，它們是：
敏捷方法
面相物件設計原則
設計模式
uml注：跟《uml和模式應用》有較多的重合之處，不知道誰講得好。
但是有一件事我卻比以往更加清楚，那就是：交付產品的關鍵因素是人，而不是過程。我們成功的訣竅很簡單：和那些沉醉於交付軟體的人一起工作，使用適合於自己團隊的輕量過程進行開發，並且不斷去適應。
第1部分 敏捷開發（跳過，暫時不看）
第2部分 敏捷設計
在敏捷團隊中，全域性檢視和軟體一起演化。在每次迭代中，團隊改進系統設計，使設計盡可能適合於當前系統。團隊不會花費許多時間去**未來的需求和需要，也不會試圖在今天就構建一些基礎結構去支撐那些他們認為明天才會需要的特性。他們更願意關注當前的系統結構，並使它盡可能地好。
注：有疑問
第7章 什麼是敏捷設計
最後，源**就是設計。
注：以寫文件的態度來寫**，換句話說，我們不是僅僅在寫**，我們實際在寫文件，是給別人看的，不要寫出看不懂的文件
如果設計中包含有當前沒有用的組成部分，它就含有不必要的複雜性。當開發人員**需求的變化，並在軟體中放置了處理那些潛在變化的**時，常常會出現這種情況。起初，這樣看起來像是一件好事。畢竟，為將來的變化做準備會保持**的靈活性，並且可以避免以後再進行痛苦的改動。
糟糕的是，結果常常正好相反。為過多的可能性做準備，致使設計中含有絕對不會用到的結構，從而變得混亂。一些準備也許會帶來回報，但是更多的不會。期間，設計揹負著這些不會用到的部分，使軟體變得複雜，並且難以理解。
注：如何把握呢
敏捷團隊依靠變化來獲取活力。團隊幾乎不進行預先設計，因此，不需要乙個成熟的初始設計。他們更願意保持系統設計盡可能的乾淨、簡單，並使用許多單元測試和驗收測試作為支援。這保持了設計的靈活性、易於理解性。團隊利用這些靈活性，持續改進設計，以便於每次迭代結束所生成的系統都具有最適合於那次迭代中需求的設計。
注：我們為什麼不行呢，我覺得我們沒有持續改進設計的驅動，每次改**僅僅是為了新增功能，沒有經常回顧設計，還有就是持續改進設計對開發人員的能力要求挺高，需要他們明白設計，設計是否出問題了，該如何走向，可是我們的編碼人員哪有這能力
記住，在大多數軟體專案中最不穩定的東西就是需求。
使用敏捷開發方法時，一開始編寫的**和程式7.1中的完全一樣。在老闆要求敏捷開發人員使程式可以從紙帶讀入機讀取資訊時，他們會做出這樣的反應：修改設計並使修改後的設計對於那一類需求的變化具有彈性。
注：如果那一類需求沒出現呢，呵呵
在要實現新需求時，團隊抓住這次機會去改進設計，以便設計對於將來的同類變化具有彈性，而不是設法去給設計打補丁。從現在開始，無論何時老闆要求一種新的輸入裝置，團隊將都能以不導致copy程式退化的方式做出反應。
有人會認為他們僅僅完成了一半的工作。他們在使自己免於不同的輸入裝置帶來的麻煩時，本可以也使自己免於不同的輸出裝置帶來的麻煩。然而，團隊實在不知道輸出是否會變化。現在就新增額外的保護沒有任何現實意義。很明顯，如果需要這種保護時，以後可以非常容易地新增。因此，實在沒有現在就新增的理由。
設計必須要保持乾淨、簡單，並且額由於源**是設計最重要的表示，所以它同樣要保持乾淨。職業特性要求我們，作為軟體開發人員，不能忍受**腐化。
注：謹記
第8章 單一職責原則
敏捷軟體開發（原則，模式與實踐）
教堂尖頂上的風標，即使由鋼鐵製成，如果不懂得順應風勢的藝術，一樣會被風暴立即摧毀。海因里希.海涅 一 敏捷軟體開發宣言 1 個體和互動勝過過程和工具 人是獲得成功的最為重要的因素。合作 溝通以及互動能力要比單純的程式設計能力更為重要。乙個由平均水平程式設計師組成的團隊，如果具有良好的溝通能力，將比那...
敏捷軟體開發 原則 模式與實踐 之敏捷實踐
參與公司的敏捷開發也有一段時間了，還沒有系統的學習過敏捷開發。比如早上的站會，每個月的迭代會，還有自己領取任務去開發故事，這些都是敏捷開發的流程之一。敏捷開發需要不斷的學習，不斷的實踐。現在開始寫一些關於敏捷開發的部落格。一 敏捷聯盟 1 個體和互動勝過過程和工具 乙個優秀的團隊成員未必是乙個一流的...
敏捷軟體開發 原則 模式與實踐 （一）
為了達到敏捷開發，我們需要使用一些實踐提供必要的準則和反饋，需要使用一些設計原則使我們的軟體保持靈活且可維護，還需要理解一些已經被證明在特定問題中可以權衡這些原則的設計模式。敏捷軟體開發宣言 人和互動 重於 過程和工具 可以工作的軟體 重於 面面俱到的文件 客戶合作 重於 合同談判 隨時應對變化 重...