貌似有段時間沒寫什么博客了，有質量的博客更少，雖然寫博客的初衷是記錄自己的學習內容，類似筆記性質的東西，但也希望能更有內容，而不是空泛的一些東西。。。
最近一大堆瑣事，公司、生活，心力俱疲。節后算是找回了一些狀態，這個月的學習計划，大概就是《敏捷軟件開發》這本書。。。
這篇博客，就大概介紹下敏捷軟件開發的宣言、原則和面向對象設計的原則，以及個人的一些理解（楷體字體做區別）。。。
個人感覺，了解一種東西，一定要明白它的設計理念，才能更懂如何去學習。。。
一、敏捷軟件開發宣言
個體和互動高於流程和工具
工作的軟件高於詳盡的文檔
--注重產品本身，而不是形式和流程，文檔應簡潔易閱讀，方便維護和同步
客戶合作高於合同談判
--主動擁抱變化，及時響應，持續交付
響應變化高於遵循計划
--制定可實現的短期清晰的目標，中期的粗略的計划，長期的大方向有大概目標即可
二、敏捷宣言遵循的原則
1、我們最重要的目標，是通過持續不斷的及早交付有價值的軟件使客戶滿意。
--持續交付，快速迭代
2、欣然面對變化，即使在開發后期也一樣，為了客戶的競爭優勢，敏捷過程掌握變化。
--敏捷更多適用於互聯網企業，移動端更甚，一個機會的存在期可能短的可憐，應盡量保持軟件的靈活性，減小對系統造成的影響
3、經常交付可工作的軟件，相隔幾星期或一兩個月，傾向於采取較短的周期。
--盡早的、經常的交付可工作的滿足需求的軟件，在Google，甚至可以做到每天交付一個可工作的軟件，即beta版本
4、業務人員和開發人員必須互相合作，項目中的每一天都不例外。
--及時溝通，避免信息斷層，減少延時，隨時調整
5、激發個體的斗志，以他們為核心搭建項目，提供所需的環境和支援，輔以信任，從而打成目標。
--過程和方法對於項目的影響只有次要的影響，首要的影響是人
6、不論團隊內外，傳遞信息效果最好效率最高的方式是面對面的交談。
--郵件聽不了語氣，語音看不到表情，面對面溝通是最高效的辦法
7、可工作的軟件是進度的首要度量標准。
--最終產出物是可工作的軟件，so，快速迭代交付的重要性不言而喻，這也是衡量一個項目進度的重要的element
8、敏捷過程倡導可持續開發，負責人、開發人員和用戶要能夠共同維持其步調穩定延續。
--目標清晰，設定可實現的短期的詳細的目標，當然這種步調需要長時間的培養和鍛煉
9、堅持不懈的追求技術卓越和良好設計，敏捷能力由此增強。
--拒絕平庸，追求卓越，良好的設計能減少很多工作中后期的麻煩，比如技術負債！
10、以簡潔為本，它是極力減少不必要工作量的藝術。
--輕文檔，輕流程，重產出，重目標
11、最好的架構、需求和設計出自自組織團隊。
--想起一句話：管理的最高境界是為共同的目標，整個團隊共同承擔責任，而不是單一職權負責制
12、團隊定期的反思如何能提高成效，並因此調整自身的舉止表現。
--不斷思考總結，調優，減少不必要的資源消耗
三、面向對象設計原則
SRP：單一職責原則
就一個類而言，應該僅有一個引起它變化的原因。
OCP：開放封閉原則
軟件實體（類、模塊、函數等）應該是可擴展的，但是不可修改。
LSP：Liskov替換原則
子類型必須能替換掉他們的基本類型。
DIP：依賴倒置原則
抽象不應該依賴於細節，細節應該依賴於抽象。
ISP：接口隔離原則
不應強迫用戶依賴於他們不用的方法，接口屬於用戶，不屬於它所在的類層次結構。
REP：重用發布等價原則
重用的粒度就是發布的粒度。
CCP：共同重用原則
一個包中所有的類應該是共同重用的，如果重用了包中的一個類，那么就要重用包中的所有類，相互之間沒有緊密聯系的類不應該在同一個包中。
CRP：共同封閉原則
一個包中所有類對於同一類性質的變化應該是共同封閉的，一個變化若對一個包影響，則將對包中的所有類產生影響，而對其他包不造成任何影響。
ADP：無依賴原則
在包的依賴關系中不允許存在環，細節不應該被依賴。
SDP：穩定依賴原則
朝着穩定的方向進行依賴。
SAP：穩定抽象原則
一個包的抽象程度應該和其他穩定程度一致。
關於敏捷軟件開發模式，其宣言和原則就是上面的一些內容，后續會不斷更新相關的，關於開發設計，敏捷測試的一些內容。