偉大軟體的三步驟
1.確認你的軟體做客戶想要它做的事
2、運用基本的OO原則來增加軟體的靈活性---OO原則是什麼？
3、努力實現可維護、可重用的設計--什麼是可重用？

需求
1.好的需求確保你的系統如預期那樣運作
2.確認你的需求涵蓋所有用例
3.運用用例找出客戶忘記的事
4.你的用例將揭露任何不完整遺漏的需求，你可能需新的需求加進你的系統中
5.你的需求總是隨著時間成長

分析與設計
1.設計良好的軟體容易改變與擴充套件
2.使用像封裝與繼承這樣的基本OO原則來確保你的軟體具有靈活性
3.如果設計沒有靈活性，就改變它！別與環設計拖鞋，幾時那是你自己的設計，要改就是要改。
4.確認你的每一個類都具有內聚性：沒一個雷都應該巨劍在把一件事情做得很好上。
內聚性：每個類確保這件事發生的理由只有一個，類的改變不會一起其他類的改變
5.隨著軟體的設計生命週期的展開，要持續努力提高內聚力

OO原則
1.講變化之物封裝起來

2.對介面編碼，而不是對實現

3.應用程式的每一個類只有一個改變的理由。（內聚性）

4.類是關於行為與功能的

5.OCP(open-closed principle)開閉原則
  對擴充套件開放，對修改關閉
  擴充套件有效程式程式碼，而不是改變當中的程式程式碼
  簡單的實現方式為繼承

6.（DRY）do not repaeat yourself不自我重複原則
   通過將共同之物抽取出來並置於單一地方來避免重複的程式程式碼
   確保你對應用程式中每一個功能與需求只實現一次
   特定片段與資訊具有單一來源，該單一來源必須合理

7.SRP(single responsibility principle)單一職責原則
  每一個物件聚焦在一個職責上
  當你得每一個物件都只有一個改變的理由時，你已經正確地實現單一職責原則。
  確保單一職責的方法
  the 型別 方法名 itself 是否合理

8.LSP(liskov subsititution principle)替換原則
  子型別必須能夠替換其基型別
  LSP完全關係到設計良好的繼承。當你從一個基類繼承下來時，你必須需能用你的子類替換該基類且不會把事情弄糟，
  否則，你就錯誤地使用了繼承
  繼承必須確保父型別所擁有的特質（屬性與方法），對子型別仍然成立(有意義)

假如發現程式程式碼違反LSP，考慮利用委託,組合或聚合來使用來自其他類的行為而無需使用繼承
（子類不恩能夠替換它的基類時可能使用）
9.委託
  委託是將特定工作的責任委派給另一個類或方法
  最好在你想要使用另一個類的功能性時使用
  假如你需要使用另一個類的功能性，但不行改變該功能性，考慮以委託代替繼承

（子類不恩能夠替換它的基類時可能使用）
10.使用組合將來自其他多個類（）的行為集合起來
   當引用一整群的行為時，使用組合
   組合讓你使用來自一組其他類的行為，並且可以在執行時切換該行為
   若物件有其他物件組成，當擁有物件被銷燬時，被擁有物件（組合的一部分）也跟著消失
   在組合中，由其他行為所組成的物件用於那些行為。當物件被摧毀時，其所有行為也被摧毀。組合中的行為不存於組合本身以外。

11.聚合:組合，但沒有突然的結束
（子類不恩能夠替換它的基類時可能使用）
   聚合時當一個類被用作另一個類的一部分時，但仍然可以存在於該類之外

12.除了繼承，有幾種方式可以重用來自其他類的行為
   委託:當你不想改變其行為，而實現該行為不是此物件本身的責任時，就將行為委託給另一個類
   組合：使用組合，你可以重用來自一個或多個類的行為，特別是來自一個族群的類的行為。你得主要物件完全用於被組合物件
         ，而且被組合物件不存在主要物件之外
   聚合：當你想要組合的所有好處，但是也想要在主要物件之外使用被組合物件的行為時，就使用聚合

假如你喜歡委託、組合、聚合勝過繼承，你的軟體通常會更靈活，更易維護，擴充套件與重用。 
 

解決大問題
1.收集功能列表
2.設計用例圖，必須涵蓋系統的功能列表
  參與者：與系統互動的部分，不總是系統的使用者
3.領域分析：用客戶所用的語言檢查你得設計
4.為系統設計模組，將大問題分解成小的功能片段
5.運用設計模式幫助我們解決小的問題

架構
定義：架構是你的設計結構，強調應用程式中最重要的部件以及那些部件之間的關係
從功能入手，找出最重要的功能，可能由多個組成

架構三問：
1.他是系統本質的一部分嗎？（你能想象系統沒有這個功能嗎？）
2.這到底是什麼意思？假如你部確定某項功能的敘述究竟是什麼意思，把注意力放在改功能上可能就很重要
3.我“到底"該如何做？假如你不知道如何處理某特定問題，最好花點時間去正視該功能

從哪個最重要的功能開始？關鍵是減少風險

架構拼圖與構建場景

開發方式:
1.用例驅動開發
2.功能驅動開發
3.測試驅動開發

程式設計實踐
1.契約式程式設計為你與軟體使用者同意遵守的軟體行為建立一個共同的協議
2.防禦性程式設計不信任其他軟體，進行廣泛的錯誤及資料檢查以確保其他軟體不會給你不良的或不安全的資訊

面向物件分析設計專案的生命週期
1.功能列表:從高層次找出應用程式應該做什麼
 客戶訪談
 關鍵功能列表
 

2.用例圖：確認應用程式要執行的大流程，以及任何牽涉到的外部力量
 外部啟動器

3.分解問題：將應用程式分解成功能性模組，接著決定以什麼樣的次序處理每個模組
 架構
 分析
 共同性
 委託
 變化性

4.需求：為每個功能模組想出各自的需求，並且確定他們複合整體輪廓
 外部啟動器
 場景
 替換路徑
 迭代
 需求列表

5.領域分析：想出你的用例如何對應到應用程式理的物件，確認你課客戶跟你又相同的認識
 文字分析

6.初步設計：加入關於物件的細節，定義物件之間的關係，並且運用原則與設計模式
 封裝
 設計模式
 設計原則
 類圖
 迭代

7.實現：編寫程式程式碼，進行測試，確認它有效運作。為每個行為，每個功能，每個用例，每個問題，做這些事，直達你完成.
 OO原則
 封裝
 測試驅動
 功能驅動
 用例驅動
 測試場景

8.交付