•全域性檢視和軟體一起演化
•設計盡可能適合當前系統，關注當前系統結構
•增量地演化出系統最佳架構和設計
•設計和架構過程是持續不斷進行的
•從根本上講，源**就是設計
•敏捷設計是乙個過程，不是乙個事件，是乙個持續的應用原則、模式以及實踐來改進軟體結構和可讀性的過程
•敏捷設計步驟
–遵循敏捷實踐去發現問題
–應用設計原則去診斷問題
–應用適當模式去解決問題
•設計臭味
–僵化性（rigidity）——連鎖改動
–脆弱性（fragility）——耦合、易遭破壞
–頑固性（immobility）——難以重用
–粘滯性（viscosity）——難以做正確的事情
–不必要的複雜性（needlesscomplexity）——過度設計
–不必要的重複（needlessrepetition）——忽略抽象
–晦澀性（opacity）——難以理解
•內聚性
–乙個模組的組成元素之間的功能相關性
•srp
–乙個類應該只有乙個發生變化的原因，及乙個類應該只有乙個職責
•職責–發生變化的原因
–需求變化反應為職責的變化
•軟體設計，就是要發現職責，並把它們相互分離
•封閉是建立在抽象的基礎之上的
•只受一次愚弄
•刺激變化：測試驅動、快速交付
•正確判斷各種變化的可能
•一直等到變化發生時才採取行動
•ocp是物件導向設計的核心所在
•拒絕不成熟的抽象和抽象本身一樣重要
•ocp背後的主要機制是抽象和多型
•有經驗的設計人員希望自己對使用者和應用領域很了解，能夠以此來判斷各種變化的可能性。然後，他可以讓設計對於最有可能發生的變化遵循ocp原則
•子型別必須能夠替換掉它們的基型別，替換後，程式的行為功能不變
•乙個自相容的設計未必就和所有的使用者程式相容
•乙個模型的有效性只能通過它的客戶程式來表現
•在考慮乙個特定設計是否恰當時，不能完全孤立的來看這個解決方案，必須根據該設計的使用者所作出的合理假設來審視它（這些合理的假設常常以斷言的形式出現在為基類編寫的單元測試中）
•違反lsp往往是很微妙的
•lsp清楚的指出，ood中的is-a關係是就行為方式而言的，行為方式是可以進行合理假設的，是客戶程式所依賴的。
•使用基於契約的設計可以使lsp明確化
•基於契約的設計
–在重新宣告派生類的例程中，只能使用相等或更弱的前置條件，只能使用相等或更強的後置條件
–若違反了這條原則，則必定違反lsp原則
•為每個方法的注釋新增前置和後置條件
•通過單元測試來指定契約
•dip
–高層模組不應該依賴底層模組，二者都應該依賴於抽象
–抽象不應該依賴於細節。細節應該依賴於抽象
•框架設計的核心原則
•dip解析
–高層模組即客戶端或使用方，底層模組即服務端
–應由使用方提出所需的介面，由服務方來實現這些介面的具體功能
–因此軟體開發的過程應該是自上而下的
•抽象介面歸客戶端所有
•不應該強迫客戶程式依賴它們並不使用的方法/介面。
•分離客戶就是分離介面。
讀書筆記 AgilePPP 咖啡的啟示
程式的中心是行為 不基於行為的系統劃分，基本上是嚴重錯誤的。正是系統的行為為我們提供了第乙個關於應該如何劃分系統的線索 沒有任何成員變數 狀態 只是乙個呼叫轉換器 水蒸氣類沒有存在的必要 抽象是非常微妙的 對抽象類，多問問 誰使用它們？乙個僅僅含有抽象方法並且不具有任何使用者的類，完全是乙個無用的類...
讀書筆記 AgilePPP 咖啡的啟示
程式的中心是行為 不基於行為的系統劃分，基本上是嚴重錯誤的。正是系統的行為為我們提供了第乙個關於應該如何劃分系統的線索 沒有任何成員變數 狀態 只是乙個呼叫轉換器 水蒸氣類沒有存在的必要 抽象是非常微妙的 對抽象類，多問問 誰使用它們？乙個僅僅含有抽象方法並且不具有任何使用者的類，完全是乙個無用的類...
敏捷開發讀書筆記
1 開始時需求要明確 2 盡早發布可執行的demo，持續進行整合 3 功能粒度要足夠低 4 架構可以隨時進行調整 5 測試驅動開發 6 持續整理 及架構重構 7 持續的速度，任務分解需要細緻 粒度要小，各個模組的任務完成要及時 有效 軟體之美在於它的功能，在於它的內部結構，還在於團隊建立它的過程。對...